From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=34488 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Q90Nw-000190-0Z
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 15:33:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jljusten@gmail.com>) id 1Q90Nv-0004kI-1u
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 15:33:23 -0400
Received: from mail-pz0-f45.google.com ([209.85.210.45]:43232)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jljusten@gmail.com>) id 1Q90Nu-0004k6-Tb
	for qemu-devel@nongnu.org; Sun, 10 Apr 2011 15:33:23 -0400
Received: by pzk36 with SMTP id 36so2242696pzk.4
	for <qemu-devel@nongnu.org>; Sun, 10 Apr 2011 12:33:21 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <4DA18C33.6050002@web.de>
References: <1301861786-6637-1-git-send-email-jordan.l.justen@intel.com>
	<4DA16C6A.7090303@web.de> <4DA18C33.6050002@web.de>
Date: Sun, 10 Apr 2011 12:33:21 -0700
Message-ID: <BANLkTim4dHGBRZaj6eNrRsuiACVvCLObrw@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH] pflash: Restore & fix lazy ROMD switching
From: Jordan Justen <jljusten@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>

On Sun, Apr 10, 2011 at 03:53, Jan Kiszka <jan.kiszka@web.de> wrote:
> Commit 5145b3d1cc revealed a bug in the lazy ROMD switch-back logic, but
> resolved it by breaking that feature. This approach addresses the issue
> by switching back to ROMD after a certain amount of read accesses
> without further unlock sequences.

Without this change, the code will stay in flash mode until a single
read occurs.  The code sequence you are wanting to support using will
issue a read before trying to unlock again?

Actually, I suppose it will want to verify the written data before
moving on, so this does make sense.

Is the overhead of switching the modes significant enough to justify
the lazy switch-back?  (If so, maybe I'll look at this for cfi01 too.)

Thanks,

-Jordan