SDHC on DM365

Unfortunately as you have already concluded there is currently no easy way to get SDHC on the DM365, currently it would require some porting effort to get the capability into a kernel on the DM365. Eventually this will be supported through a GIT kernel that will work on DM365 though this may be a ways off, and I could not say when it would happen. At the moment I believe the optimal way at the moment would be to backport the mainline kernel capability into the 2.6.18 MV kernel, though I have not seen this done yet so it is hard to say how practical this would be. One suggestion for this process is to consider this patch as part of your backporting operation, though this is for DA830/OMAP-L137 the DM365 has the same SD controller and will likely need the same tweaks to function.

I have succedded in backporting the neccessary mainline changes. I didn't apply the patch you mention from the davinci tree, but it seems to work for me, at least with the SDHC card I have.

I cherry picked the following commits from the mainline. I doubt that all of these are required; I chose all the non-reorganisation patches between 2.6.18 and the commit that added SDHC support, excluding the ones that MV had already included. There were some minor fixups required to make it compile, but they were obvious.

• 132919ba
• db53f28b
• 2ed6d22c
• 7104e2d5
• 176f00ff
• ec5a19dd
• 25a122fd
• 63ef731a
• 73778120
• 7ccd266e
• 8b7feff8
• f22ee4ed
• fba68bd2

Robin, this is great!  Thank you for sharing this with our community.

Hello Robin,

Thank you for your backporting.

We are working on the DM365 and we are trying to get SDHC cards working.

We tried to apply patches from your post, but it seems we don’t have the same kernel version by starting. (for example : driver/mmc/davinci.c is not affect by the patch)

Our kernel is: Linux 192.168.2.160 2.6.18_pro500-davinci_evm-arm_v5t_le

Do you have an idea to find an issue to this problem? Thanks

Loïc

Hi Loïc,

I started with LSP 02_10_00_11. As I mentioned, the patches do not apply cleanly, but the fix ups are easy. The fix-ups to drivers/mmc/davinci.c are the most extensive (as the driver doesn't exist in the mainline), but still small...

commit ba58e94687efc7859660f53661039716754a4acd
Author: Chris Paulson-Ellis <chris@edesix.com>
Date:   Tue May 26 13:59:23 2009 +0100

    Reconcile MV/davinci with blksz_bits removal

diff --git a/drivers/mmc/davinci.c b/drivers/mmc/davinci.c
index cededd8..4ee6758 100644
--- a/drivers/mmc/davinci.c
+++ b/drivers/mmc/davinci.c
@@ -614,7 +614,6 @@ static int mmc_davinci_start_dma_transfer(struct mmc_davinci_host *host,
 {
        int use_dma = 1, i;
        struct mmc_data *data = host->data;
-       int block_size = (1 << data->blksz_bits);

        host->sg_len = dma_map_sg(host->mmc->dev, data->sg, host->sg_len,
                                  ((data->
@@ -623,7 +622,7 @@ static int mmc_davinci_start_dma_transfer(struct mmc_davinci_host *host,

        /* Decide if we can use DMA */
        for (i = 0; i < host->sg_len; i++) {
-               if ((data->sg[i].length % block_size) != 0) {
+               if ((data->sg[i].length % data->blksz) != 0) {
                        use_dma = 0;
                        break;
                }
@@ -733,7 +732,7 @@ static void mmc_davinci_prepare_data(struct mmc_davinci_host *host,
                (req->data->flags & MMC_DATA_STREAM) ? "stream" : "block",
                (req->data->flags & MMC_DATA_WRITE) ? "write" : "read",
                req->data->timeout_clks, req->data->timeout_ns,
-               req->data->blocks, 1 << req->data->blksz_bits);
+               req->data->blocks, req->data->blksz);

        /* Convert ns to clock cycles by assuming 20MHz frequency
         * 1 cycle at 20MHz = 500 ns
@@ -744,7 +743,7 @@ static void mmc_davinci_prepare_data(struct mmc_davinci_host *host,

        DAVINCI_MMC_WRITEW(host, TOD, timeout);
        DAVINCI_MMC_WRITEW(host, NBLK, req->data->blocks);
-       DAVINCI_MMC_WRITEW(host, BLEN, (1 << req->data->blksz_bits));
+       DAVINCI_MMC_WRITEW(host, BLEN, req->data->blksz);
        host->data_dir = (req->data->flags & MMC_DATA_WRITE) ?
            DAVINCI_MMC_DATADIR_WRITE : DAVINCI_MMC_DATADIR_READ;

@@ -778,7 +777,7 @@ static void mmc_davinci_prepare_data(struct mmc_davinci_host *host,
        sg_len = (req->data->blocks == 1) ? 1 : req->data->sg_len;
        host->sg_len = sg_len;

-       host->bytes_left = req->data->blocks * (1 << req->data->blksz_bits);
+       host->bytes_left = req->data->blocks * req->data->blksz;

        if ((host->use_dma == 1) && (host->bytes_left % host->rw_threshold == 0)
            && (mmc_davinci_start_dma_transfer(host, req) == 0)) {
@@ -916,7 +915,7 @@ static void mmc_davinci_xfer_done(struct mmc_davinci_host *host,
        host->data = NULL;
        host->data_dir = DAVINCI_MMC_DATADIR_NONE;
        if (data->error == MMC_ERR_NONE)
-               data->bytes_xfered += data->blocks * (1 << data->blksz_bits);
+               data->bytes_xfered += data->blocks * data->blksz;

        if (host->do_dma) {
                davinci_abort_dma(host);

Great, it works... Thanks very much Robin

Loïc

Hello Robin,

I am looking to do something similar for the dm365. That is, to backport SDIO support into the 2.6.18 kernel (LSP 02_10_00_11) for use with an SDIO WiFi card (http://e2e.ti.com/forums/p/6567/25154.aspx#25154).

I am somewhat a novice git user, so I wondered if you could tell me how you went about finding the patches between the 2.6.18 version (of the davinci git tree) and the addition of the SDIO support (assuming I can find where that is by searching the commit logs)?

Any help would be appreciated. Thanks so much.

Best regards,

-Craig