OK, I can see your point here. However, this is a completely different
change to my original patch. Would it not make more sense to queue my
original patch and then for me to write some patches to move all the

Again, this is a good idea but a different change to the patch I wrote
originally.

So, what I propose is this. Could you please queue my bug fix (I can
send the two patches again) and then I will begin working on the
generic patches to fix the issues that you've raised in this thread?
How does that sound?
--

[ message continues ]

On Mon, 15 Sep 2008 10:24:22 +0100

It's better to get it right directly. I'd consider this a bug fix

It shouldn't take that long to write the more proper solution, so get
to it and it should be possible to get in even for .27.

-- 
     -- 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.
--

[ message continues ]

OK, attached is the latest attempt at this patch. Because a lot of
host drivers manipulate timeout_ns and timeout_clks I decided not
touch them at all. So, I created a new member of the mmc_data struct
that has the timeout value as a ktime_t. I'm still unsure of how
exactly to tackle the mmc_send_cid and mmc_send_csd() cases, the
timeout value used in the spec is Ncr, where can I find this value?


diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 044d84e..b5c6f5f 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -249,8 +249,10 @@ void mmc_set_data_timeout(struct mmc_data *data,
const struct mmc_card *card)
         * SDIO cards only define an upper 1 s limit on access.
         */
        if (mmc_card_sdio(card)) {
-               data->timeout_ns = 1000000000;
-               data->timeout_clks = 0;
+               if (data->timeout_ns > 1000000000) {
+                       data->timeout_ns = 1000000000;
+                       data->timeout_clks = 0;
+               }
                return;
        }

@@ -269,6 +271,11 @@ void mmc_set_data_timeout(struct mmc_data *data,
const struct mmc_card *card)
        data->timeout_ns = card->csd.tacc_ns * mult;
        data->timeout_clks = card->csd.tacc_clks * mult;

+       data->ktimeout = ktime_set(0, 0);
+       data->ktimeout = ktime_add_ns(data->ktimeout, data->timeout_ns);
+       data->ktimeout = ktime_add_ns(data->ktimeout,
+               data->timeout_clks * 1000000 / card->host->ios.clock);
+
        /*
         * SD cards also have an upper limit on the timeout.
         */
@@ -290,6 +297,8 @@ void mmc_set_data_timeout(struct mmc_data *data,
const struct mmc_card *card)
                if (timeout_us > limit_us || mmc_card_blockaddr(card)) {
                        data->timeout_ns = limit_us * 1000;
                        data->timeout_clks = 0;
+                       data->ktimeout = ktime_add_ns(ktime_set(0, 0),
+                                               ...
[ message continues ]

On Wed, 24 Sep 2008 12:16:02 +0100

Hmm... What do you mean manipulate? They all just read it, so I don't

Right, they left that out of the simplified spec. Sneaky bastards. It's

data->timeout_* is undefined when this function is invoked, so this

card->host->ios.clock is just the upper bound on the clock, it might be
running slower. This is why the host driver needs to calculate it (well
that, and the fact that different controllers treat timeouts in

If you put the calculation somewhere before this chunk instead,
everything should be peachy.

Rgds
-- 
     -- 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.
--

[ message continues ]