From mboxrd@z Thu Jan  1 00:00:00 1970
From: =?iso-8859-1?Q?Br=FCns=2C_Stefan?= <Stefan.Bruens@rwth-aachen.de>
Date: Mon, 3 Apr 2017 18:24:08 +0000
Subject: [U-Boot] [PATCH v5 02/19] usb: dwc2: Use separate input and
 output buffers
In-Reply-To: <1839232.Ocurkfb8WW@sbruens-linux>
References: <20170401180556.2416-1-sjg@chromium.org>
 <CAPnjgZ0hpR2iWvhZe8QxFrpOkMaG1-uOfWmZxv6h7LcdGxSMAQ@mail.gmail.com>
 <1839232.Ocurkfb8WW@sbruens-linux>
Message-ID: <1636070.mxeDJnAFIs@sbruens-linux>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
To: u-boot@lists.denx.de

On Montag, 3. April 2017 20:18:42 CEST Br=C3=BCns, Stefan wrote:
> On Montag, 3. April 2017 17:38:40 CEST you wrote:
> >=20
> > What am I missing?
>=20
> The following is a gross oversimplification, but might explain it:
>=20
> 1. Assume all of the 64kB of the aligned_buffer is dirty. (Likely, if the
> buffer is calloced.)
> 2. We are doing some transfers. All transfers are small, e.g. 64 byte.
> 3. In accordance with the two cases you mentioned above, the first 64 byte
> are no longer dirty, as the last out transfer has flushed the cacheline. =
4.
> We are doing our first large in transfer (i.e. larger than 64 byte). 5. B=
ad
> Things (TM) may happen to any data at aligned_buffer[64] and beyond.
>=20
> If this holds, a single invalidate_dcache_range(aligned_buffer,
> aligned_buffer +65536,...) during the initialization of the controller
> would suffice.

I just read "[U-Boot] [PATCH] usb: dwc3: gadget: make cache-maintenance on =

event buffers more robust" from Philipp Tomsich, which mentions the same=20
problem:

The original code was doing the following (on AArch64, which
translates a 'flush' into a 'clean + invalidate'):
  # during initialisation:
      1. allocate buffers via memalign
         =3D> buffers may still be modified (cached, dirty)
  # during interrupt processing
      2. clean + invalidate buffers
         =3D> may commit stale data from a modified cacheline
      3. read from buffers

This could lead to garbage info being written to buffers before
reading them during even-processing.

To make the event processing more robust, we use the following sequence
for the cache-maintenance:
  # during initialisation:
      1. allocate buffers via memalign
      2. clean + invalidate buffers
         (we only need the 'invalidate' part, but dwc3_flush_cache()
          always performs a 'clean + invalidate')


Kind regards,

Stefan