Re: [patch 3/4 2.6.23-rc2 + mm2-git-mmc] MMC core learns about SPI

From: Jan Nikitenko <jan.nikitenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Pierre Ossman <drzeus-mmc-p3sGCRWkH8CeZLLa646FqQ@public.gmane.org>
Cc: Hans-Peter Nilsson
	<hans-peter.nilsson-VrBV9hrLPhE@public.gmane.org>,
	David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>,
	Mikael Starvik <mikael.starvik-VrBV9hrLPhE@public.gmane.org>,
	Mike Lavender
	<mike-UTnDXsALFwNjMdQLN6DIHgC/G2K4zDHf@public.gmane.org>,
	spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [patch 3/4 2.6.23-rc2 + mm2-git-mmc] MMC core learns about SPI
Date: Tue, 23 Oct 2007 10:06:09 +0200	[thread overview]
Message-ID: <471DAB71.8000808@gmail.com> (raw)
In-Reply-To: <20071022203428.300117e4-mgABNEgzgxm+PRNnhPf8W5YgPPQkE1Si@public.gmane.org>

Pierre Ossman wrote:
> On Fri, 19 Oct 2007 11:50:16 +0200
> "Jan Nikitenko" <jan.nikitenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
>> On 10/10/07, Pierre Ossman <drzeus-mmc-p3sGCRWkH8CeZLLa646FqQ@public.gmane.org> wrote:
>>> Odd. Could you point to the byte swapping in the earlier version?
>> It was present in mmc-spi update patch posted here for example:
>> http://sourceforge.net/mailarchive/message.php?msg_id=200706042025.18252.david-b%40pacbell.net
>> Check the mmc_spi_read_cXd(), there are be32_to_cpus() calls present.
>>
> 
> Ah. I see what you mean now. The problem is in the data transfer, not a response field. So Sacha's patch was almost correct. Could you test if the included patch solves your issue?

With your patch it works as good as with the one from Sascha.

>> Without the !blk_queue_stopped(q) check, the suspend waits until dd
>> command finishes it's  job.
> 
> Not quite. It should just wait for the data dd has currently queued up (which should be 1 bs plus possible read-ahead).
> 
>> If the check is there, it's possible to suspend when dd command (or
>> any other file copy command) is running and properly resume after.
>>
> 
> OTOH, letting them finish reduces the number of dirty pages that might have to be committed to disk for a hibernation.

That's true.

> 
> Is this really a problem that plagues you, or just something you noticed in the code?

It is that we need to suspend as soon as possible because of power loss.
Waiting to flush all the caches does not help, because there will not be
enough time with backup power. So it's better not to start any new block
requests to safe as much backup power as possible and to avoid
interrupted block transfer.

Best regards,
Jan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/