David, > > > > > - if (!host->do_dma && (host->data_dir == > DAVINCI_MMC_DATADIR_WRITE)) > > > > > - davinci_fifo_data_trans(host, 32); > > > > > + if (!host->do_dma && (host->data_dir == > DAVINCI_MMC_DATADIR_WRITE) > > > && > > > > > + ((cmd->opcode == MMC_WRITE_BLOCK) || > > > > > + (cmd->opcode == MMC_WRITE_MULTIPLE_BLOCK))) > > > > > + davinci_fifo_data_trans(host, > DAVINCI_MMC_FIFO_SIZE_BYTE); > > > > > > from > > > working, for example? Would a simple "host->data != NULL" address the > > > same > > > issue? Can DATADIR_WRITE even be set to that value for a non-write > > > command? > > > > > > There are non-MMC/non-SD write commands... > > > > Please refer to the TRM > > This is required only in case of non dma based transfers and that too > > during write operation. > > Exactly. But there are more write transactions than those two; > they just happen to be some of the most common ones. > > And from what I could see, the existing code already covered all > of the cases: all write transactions (i.e. everything that sends > a DATA stage to the card, using DAT0..DATx) was filling the fifo. > > Although there does seem to be a bug there ... it should never > fill the fifo with more data than is being sent.
This required by SD controller as suggested by IP designer. Please look at SD controller spec at http://www.ti.com/litv/pdf/sprue30d. Please check section 3.2/3.6 and point no 11/10 in the controller spec. It does not talk about priming by 32 bytes for any other command. This restriction is from SD controller. > > > > > - /* record how much data we transferred */ > > > > > - temp = readl(host->base + DAVINCI_MMCNBLC); > > > > > - data->bytes_xfered += (data->blocks - temp) * data->blksz; > > > > > - > > > > > /* reset command and data state machines */ > > > > > temp = readl(host->base + DAVINCI_MMCCTL); > > > > > writel(temp | MMCCTL_CMDRST | MMCCTL_DATRST, > > > > > > This doesn't look right ... doesn't it introduce misbehavior > > > in some of the "mmctest" cases? It's at least under-reporting > > > the number of bytes transferred (and needlessly so). > > > > This function is an abort data call which happens during timeout > > or crc errors. There is no way to tell how much of the data has > > been transferred, as it is not acknowledged. > > Well, by *observation* that register gives the correct answer. > Its value seems to get decremented by the ACK ... as implied by > the documentation. > As per TRM it indicates how many blocks are remaining to be transferred. I did not find that it is decremented on ACK. ~Vipin _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
