From: Pierre Ossman <drzeus-mmc@drzeus.cx>
To: Purushotam Kumar <purushotam@ti.com>
Cc: davinci-linux-open-source@linux.davincidsp.com,
linux-kernel@vger.kernel.org, purushotam@ti.com
Subject: Re: [PATCH 1/1] DaVinci: MMC: MMC/SD controller driver for DaVinci/DM6446.
Date: Sun, 22 Mar 2009 16:12:20 +0100 [thread overview]
Message-ID: <20090322161220.15faeb00@mjolnir.ossman.eu> (raw)
In-Reply-To: <1237214559-31345-1-git-send-email-purushotam@ti.com>
On Mon, 16 Mar 2009 20:12:39 +0530
Purushotam Kumar <purushotam@ti.com> wrote:
> +
> +/* PIO only */
> +static void mmc_davinci_sg_to_buf(struct mmc_davinci_host *host)
> +{
> + struct scatterlist *sg;
> +
> + sg = host->data->sg + host->sg_idx;
You cannot do this to scatterlists any more. You need to use the
iterator functions to walk the list.
> + host->buffer_bytes_left = sg_dma_len(sg);
> + host->buffer = sg_virt(sg);
> + if (host->buffer_bytes_left > host->bytes_left)
> + host->buffer_bytes_left = host->bytes_left;
> +}
This is not HIGHMEM compatible. Probably not any issue right now, but
might be in the future.
> + /* Setting initialize clock */
> + if (cmd->opcode == 0)
> + cmd_reg |= MMCCMD_INITCK;
This is not good. What does this do and is it really needed?
> + /*
> + * Before non-DMA WRITE commands the controller needs priming:
> + * FIFO should be populated with 32 bytes
> + */
> + if (!host->do_dma && (host->data_dir == DAVINCI_MMC_DATADIR_WRITE))
> + davinci_fifo_data_trans(host, 32);
What if the transfer is smaller than 32 bytes?
> + /* We know sg_len and ccnt will never be out of range because
> + * we told the block layer to ensure that it only hands us one
mmc layer really
> + * scatterlist segment per EDMA PARAM entry. Update the PARAM
> + * entries needed for each segment of this scatterlist.
> + */
> + for (slot = channel, link = 0, sg = data->sg, sg_len = host->sg_len;
> + sg_len-- != 0 && bytes_left;
> + sg++, slot = host->links[link++]) {
Incorrect way of traversing the sg list. Use sg_next().
> + /* Convert ns to clock cycles by assuming 20MHz frequency
> + * 1 cycle at 20MHz = 500 ns
> + */
> + timeout = data->timeout_clks + data->timeout_ns / 500;
> + if (timeout > 0xffff)
> + timeout = 0xffff;
So this might time out too early if we run at a lower clock frequency?
> + if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN) {
> + u32 temp;
> + open_drain_freq = ((unsigned int)cpu_arm_clk
> + / (2 * MMCSD_INIT_CLOCK)) - 1;
> + temp = readl(host->base + DAVINCI_MMCCLK) & ~0xFF;
> + temp |= open_drain_freq;
> + writel(temp, host->base + DAVINCI_MMCCLK);
Why are you ignoring the given frequency if in open drain mode?
> +static void
> +davinci_abort_data(struct mmc_davinci_host *host, struct mmc_data *data)
> +{
> + u32 temp;
> +
> + /* record how much data we transferred */
> + temp = readl(host->base + DAVINCI_MMCNBLC);
> + data->bytes_xfered += (data->blocks - temp) * data->blksz;
> +
Does MMCNBLC record how many blocks you've sent, or how many blocks
that the card has acked? If it's not the latter, then you cannot use it
for bytes_xfered.
> +
> + if (qstatus & MMCST0_DATDNE) {
> + /* All blocks sent/received, and CRC checks passed */
> + if (data != NULL) {
> + if ((host->do_dma == 0) && (host->bytes_left > 0)) {
> + /* if datasize < rw_threshold
> + * no RX ints are generated
> + */
> + davinci_fifo_data_trans(host, host->bytes_left);
> + }
> + end_transfer = 1;
> + data->bytes_xfered += data->blocks * data->blksz;
Why += and not =?
> +
> + if (qstatus & MMCST0_CRCRS) {
> + /* Command CRC error */
> + dev_dbg(mmc_dev(host->mmc), "Command CRC error\n");
> + if (host->cmd) {
> + /* Ignore CMD CRC errors during high speed operation */
> + if (host->mmc->ios.clock <= 25000000)
> + host->cmd->error = -EILSEQ;
> + end_command = 1;
> + }
> + }
?!!
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
next prev parent reply other threads:[~2009-03-22 15:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-16 14:42 Purushotam Kumar
2009-03-16 18:14 ` Trilok Soni
2009-03-17 10:14 ` Kumar, Purushotam
2009-03-16 18:40 ` David Brownell
2009-03-17 7:25 ` Kumar, Purushotam
2009-03-16 21:08 ` David Brownell
2009-03-17 7:30 ` Kumar, Purushotam
2009-03-22 15:12 ` Pierre Ossman [this message]
2009-03-26 8:58 ` Kumar, Purushotam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090322161220.15faeb00@mjolnir.ossman.eu \
--to=drzeus-mmc@drzeus.cx \
--cc=davinci-linux-open-source@linux.davincidsp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=purushotam@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®