Hi Marek,
On Monday, February 03, 2014 at 12:06:59 PM, Lukasz Majewski wrote:
Hi Marek,
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 ?
Let's suppose, that I will receive 2063B = [(64 * 32) + 16 -1] from UDC. If the passed buffer was exactly 2063 B in size, then we would have here a data corruption.
However this situation will not happen
_Should_ not happen ... I am absolutelly positive someone will be bitten by such assumption. I think this assumption about buffer alignment should really be documented somewhere.
I will add verbose commit message for this.
since the buffer at gadget is allocated with DEFINE_CACHE_ALIGN_BUFFER() or is an aligned multiplication of cache line size (like 1MiB).
I think, that it is the responsibility of gadget developer to allocate buffers with proper alignment and size.
Document that please, I doubt this is documented anywhere, but it's clearly part of the API. Also, some checks might be put in place for the alignment , they might be in #ifdef DEBUG for all I care, but it would be nice to have such a check, since I'm worried someone will really be bitten.
I rely on the code embedded at cache_v7.c. It works and saved me a lot of trouble (since it always print "ERROR" when buffer alignment and size is wrong).
Also I think, that those checks shall be done at invalidate_* and flush_* cache routines, not at USB driver.
You might actually want to check for this condition and throw a warning in such a case.
The check is already implemented at ./arch/arm/cpu/armv7/cache_v7.c.
Yeah, for arm926ejs core as well. Maybe that check shall be shifted into the cache management routine prototypes somehow ... not all CPUs implement that check :-(
Maybe other ARM architectures shall have the cache management code updated to work in a similar way to cache_v7.c ?
It complains with "ERROR" message when start or end address is not aligned (that is how I've discovered the unaligned buffers at UMS).
Yes.
I understand your argument with trying to not trash data, but then you will get a corruption during transfer, right ?
After applying those patches, the cache management would be performed when the USB request is completed (in the UDC).
The only requirement for UDC is the correctly allocated buffer at gadget.
Got it.
I will emphasize the need of correct buffer allocation at commit message and add some comment to UDC in the v2.