On 29 July 2013 09:44, Andy Green wrote:
> Looping Will...
>
> On 29 July 2013 16:28, Dirk Behme wrote:
>> On 26.07.2013 15:42, Andy Green wrote:
>>>
>>> On 26 July 2013 20:58, Wolfgang Denk wrote:
>>
>> ...
you not make sure that you provide optimized implementations for such
fun
Looping Will...
On 29 July 2013 16:28, Dirk Behme wrote:
> On 26.07.2013 15:42, Andy Green wrote:
>>
>> On 26 July 2013 20:58, Wolfgang Denk wrote:
>
> ...
>>>
>>> you not make sure that you provide optimized implementations for such
>>> functions and consequently #define __HAVE_ARCH_MEMMOVE (an
On 26.07.2013 15:42, Andy Green wrote:
On 26 July 2013 20:58, Wolfgang Denk wrote:
...
you not make sure that you provide optimized implementations for such
functions and consequently #define __HAVE_ARCH_MEMMOVE (and
__HAVE_ARCH_MEMCPY) ?
Yes I found these afterwards... performance is slight
Dear Andy Green,
In message
you wrote:
>
> Given that code should perferably never be used, maybe it should print
> a warning like "Using default memory ops" and leave it like it is.
> The problem is not correctness just inefficiency.
Agreed. You found a problem, and a way to improve it. All t
Dear Wolfgang Denk,
On 27 July 2013 03:06, Wolfgang Denk wrote:
> Dear Andy Green,
>
> In message
> you
> wrote:
>>
>> > Instead of making assumptions on the performance of memcpy() and
>>
>> As I wrote, I measured the performance and got a very big gain, it's
>> 3x faster on my setup to use m
Dear Andy Green,
In message
you wrote:
>
> > Instead of making assumptions on the performance of memcpy() and
>
> As I wrote, I measured the performance and got a very big gain, it's
> 3x faster on my setup to use memcpy() then default memmove().
Yes, in your single test case of copying a Lin
On 26 July 2013 20:58, Wolfgang Denk wrote:
> Dear Andy Green,
>
> In message <20130726065323.27333.82421.stgit@localhost.localdomain> you wrote:
>> While studying the reason why kernel copy from NOR was so slow on our
>> platform,
>> I realized U-Boot is pulling it from 32-bit NOR in 8-bit chunk
Dear Andy Green,
In message <20130726065323.27333.82421.stgit@localhost.localdomain> you wrote:
> While studying the reason why kernel copy from NOR was so slow on our
> platform,
> I realized U-Boot is pulling it from 32-bit NOR in 8-bit chunks needlessly.
>
> bootm uses memmove() and that just
While studying the reason why kernel copy from NOR was so slow on our platform,
I realized U-Boot is pulling it from 32-bit NOR in 8-bit chunks needlessly.
bootm uses memmove() and that just takes the approach by default to move u8s
around.
This optimization prefers memcpy() implementation (done
