From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Sat, 1 Feb 2014 23:55:04 +0100
Subject: [U-Boot] [PATCH 4/6] usb:udc:samsung: Zero copy approach for
	data passed to Samsung's UDC driver
In-Reply-To: <20140201120529.5a494cf0@jawa>
References: <1391170589-14340-1-git-send-email-l.majewski@samsung.com>
	<201402010355.20302.marex@denx.de> <20140201120529.5a494cf0@jawa>
Message-ID: <201402012355.04878.marex@denx.de>
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

On Saturday, February 01, 2014 at 12:05:29 PM, Lukasz Majewski wrote:
> On Sat, 1 Feb 2014 03:55:20 +0100
> 
> Marek Vasut <marex@denx.de> wrote:
> > On Friday, January 31, 2014 at 01:16:27 PM, Lukasz Majewski wrote:
> > > The Samsung's UDC driver is not anymore copying data from USB
> > > requests to data aligned internal buffers. Now it works directly in
> > > data allocated in the upper layers like UMS, DFU, THOR.
> > > 
> > > This change is possible since those gadgets now take care to
> > > allocate buffers aligned to cache line (CONFIG_SYS_CACHELINE_SIZE ).
> > > 
> > > Previously the UDC needed to copy this data to internal aligned
> > > buffer to prevent from unaligned access exceptions.
> > > 
> > > Test condition
> > > - test HW + measurement: Trats - Exynos4210 rev.1
> > > - test HW Trats2 - Exynos4412 rev.1
> > > 400 MiB compressed rootfs image download with `thor 0 mmc 0`
> > > 
> > > Measurement:
> > > Transmission speed: 27.04 MiB/s
> > > 
> > > Change-Id: I1df1fbafc72ec703f0367ddee3fedf3a3f5523ed
> > > Signed-off-by: Lukasz Majewski <l.majewski@samsung.com>
> > > Cc: Marek Vasut <marex@denx.de>
> > 
> > You should use ROUND_UP(), not ROUND() throughout the patch.
> > Otherwise you might fail to flush/invalidate the last little bit of
> > data in some cacheline.
> 
> I might overlooked something, so please correct me if needed.
> 
> I allocate buffers in gadgets which are aligned to cache line with
> starting address and its size is a multiplication of cache line size
> (so I will not trash data allocated next to it when I invalidate cache).
> 
> In the code I'm using ROUND to invalidate/flush more data than needed
> (ROUND(176, 32) = 192). I'm prepared for this since buffer in gadget is
> properly allocated (with DEFINE_CACHE_ALIGN_BUFFER() which uses
> roundup() internally).

The problem is in case you receive buffer which is aligned to cacheline with 
it's start, but is [(k * cacheline_size) + (cacheline_size / 2) - 1] big. I 
think it's unlikely, but if this happens, you will get corruption, right ? You 
might actually want to check for this condition and throw a warning in such a 
case.

I understand your argument with trying to not trash data, but then you will get 
a corruption during transfer, right ?

Best regards,
Marek Vasut