From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerry Van Baren <gerald.vanbaren@ge.com>
Date: Tue, 27 Oct 2009 09:21:25 -0400
Subject: [U-Boot] non-blocking flash functions - is this
	possible/acceptable?
In-Reply-To: <20091027125146.GA3216@leila.ping.de>
References: <20091027125146.GA3216@leila.ping.de>
Message-ID: <4AE6F3D5.5060403@ge.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Wolfgang Wegner wrote:
> Hi,
> 
> we have an update protocol that normally relies on data being
> received while the previous block is written to flash.
> 
> We hacked our U-Boot to provide non-blocking variants for flash
> access for the relevant functions, which are:
> 
> flash_status_check_nb()
> flash_full_status_check_nb()
> flash_erase_nb() (single-sector only)
> flash_write_cfibuffer_nb()
> write_buff_nb()
> 
> Apart from flash_status_check_nb() and flash_erase_nb() (the latter
> being reduced to handle only one sector at a time), these are mainly
> the same functions as the originals, but use
> flash_[full_]status_check_nb()
> instead, so there is much duplicate code.
> 
> Is such a use case generally acceptable in U-Boot, and if so,

I'll defer to Wolfgang Denk, Stefan Roese, (Scott Wood?), and others for 
this half.

My 2c: Overlapping data transfer with flash erase/write operations can 
be beneficial as it can reduce the programming time substantially. 
(Erase is less beneficial than write since erases don't happen as often 
and take a relatively long time, so the overlap optimization savings is 
a smaller percentage of the total erase time - Amdahl's Law.)

> anybody have an idea how to implement those without all this duplicate
> code?

Move the code to the non-blocking functions (which you have already 
done), and then implement the blocking versions as wrappers that simply 
call the non-blocking write followed by a loop calling 
flash_status_check_nb() until the write is complete.  For erase, you 
would need a loop to do the multi-sector erase as multiple non-blocking 
+ wait operations.

> Of course I can also implement this stuff in our board code, but it
> seems a bit unlogical to break the flash handling apart and the bloat
> would remain, just in a different place.

Yes, that would be horrible.

> [I am bringing this topic up because I am trying to prepare patches for
> sending to the list, and this one seems to me as a real show-stopper
> right now.]
> 
> Regards,
> Wolfgang

Best regards,
gvb