Hi All,
I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel
and modules. I select to compile all codecs as modules:
"config SND_SOC_ALL_CODECS
tristate "Build all ASoC CODEC drivers"
"
as M and I2C/SPI too.
Then in the kernel dir, run "make" to get both vmlinux and modul
Hi Barry. I think the toolchain is operating correctly here. The
current version recognises a divide followed by a modulo and optimises
this into a call to the standard EABI function __aeabi__uldivmod().
Note the code:
do_div(Kpart, source);
K = Kpart & 0x;
/* C
Hi Michael,
2011/4/26 Michael Hope :
> Hi Barry. I think the toolchain is operating correctly here. The
> current version recognises a divide followed by a modulo and optimises
> this into a call to the standard EABI function __aeabi__uldivmod().
> Note the code:
>
> do_div(Kpart, source)
2011/4/26 Barry Song <21cn...@gmail.com>:
> Hi Michael,
>
> 2011/4/26 Michael Hope :
>> Hi Barry. I think the toolchain is operating correctly here. The
>> current version recognises a divide followed by a modulo and optimises
>> this into a call to the standard EABI function __aeabi__uldivmod().
Yip, so the compiler spots these two lines:
Ndiv = target / source;
Nmod = target % source;
and turns them into
Ndiv, Nmod = __aeabi_uldivmod(target, source)
Depending on the policy of the kernel developers, you should either
implement __aeabi_uldivmod in lib1funcs.asm or use
On Tue, 26 Apr 2011, Michael Hope wrote:
> Hi Barry. I think the toolchain is operating correctly here. The
> current version recognises a divide followed by a modulo and optimises
> this into a call to the standard EABI function __aeabi__uldivmod().
> Note the code:
>
> do_div(Kpart, s
On Tue, 26 Apr 2011, Michael Hope wrote:
> Yip, so the compiler spots these two lines:
> Ndiv = target / source;
> Nmod = target % source;
>
> and turns them into
> Ndiv, Nmod = __aeabi_uldivmod(target, source)
Why would gcc do that? All four variables involved here are of t
