[U-Boot] [PATCH 1/6] usb: ehci: mx6: Add support for i.MX6SL

[Igor Grinberg]

Hi Nikolay,

On 06/17/14 20:49, Nikolay Dimitrov wrote:
> Hi Igor,
> 
> On 6/17/2014 9:26 AM, Igor Grinberg wrote:
>> That is exactly what we do already (code is on the way) and IMO what we should aim for.
> I really didn't knew this in the beginning before seeing your answers, this would be definitely easier
> to support.
> 
>> For me it is just an artificial complication which prevents single binary for
>> i.MX6 based boards.
>> Don't get me wrong, I think that in your board code you can choose which
>> approach you want, whether it will be single or multi binary, but this
>> is i.MX6 (and possibly future i.MX*) USB code which can be used on many
>> i.MX6 boards.
> I definitely like the idea, no argument on this.
> 
>> Again, what are we talking about? A couple of bytes? 
> I think it will cost 22 additional bytes per check. Here's a rough example:
> 
> (Code that just assigns the address to the struct pointer -> 10 bytes)
>     p = (mx6_usb_t*)0x55667788;
>     8380:       f247 7388       movw    r3, #30600      ; 0x7788
>     8384:       f2c5 5366       movt    r3, #21862      ; 0x5566
>     8388:       60fb            str     r3, [r7, #12]
> 
> 
> (Code that checks in runtime the CPU type -> 32 bytes)
>     if (is_imx6q())
>     8380:       f7ff ffee       bl      8360 <is_imx6q>
>     8384:       4603            mov     r3, r0
>     8386:       2b00            cmp     r3, #0
>     8388:       d005            beq.n   8396 <main+0x26>
>     {
>         p = (mx6_usb_t*)0x11223344;
>     838a:       f243 3344       movw    r3, #13124      ; 0x3344
>     838e:       f2c1 1322       movt    r3, #4386       ; 0x1122
>     8392:       60fb            str     r3, [r7, #12]
>     8394:       e004            b.n     83a0 <main+0x30>
>     }
>     else
>     {
>         p = (mx6_usb_t*)0x55667788;
>     8396:       f247 7388       movw    r3, #30600      ; 0x7788
>     839a:       f2c5 5366       movt    r3, #21862      ; 0x5566
>     839e:       60fb            str     r3, [r7, #12]
>     }
> 
> If I assume that we have 20 sub-systems in U-Boot, and each needs to check the CPU type
> in 10 places, this makes 4400 bytes difference, which is roughly the size of a moderately
> small driver in U-Boot.

This looks like a very rough estimation.
It also can be improved by various ways.

Anyway, I think that even 4K addition is an acceptable compromise for a
single binary.

> I need to say that I'm in no way expert in ARM assembly, so please
> feel free to point out any mistakes in my assumptions.
> 
> Please don't get me wrong - I don't want to argue at all. I was just wondering about this topic
> and decided to check with you guys just to be sure.

No problem.


-- 
Regards,
Igor.