OMAP3: Warning: swp{b} use is deprecated for this architecture

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Jean Pihet]

Hi,

The following warning is issued by the compiler (gcc version 4.4.1
(Sourcery G++ Lite 2010q1-202):
arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
for this architecture

Does this need fixing? If so any hint on how to do it?

Here is the offending code excerpt:

wait_sem:
        mov     r0,#1
        ldr     r1, sdrc_scratchpad_sem
wait_loop:
        ldr     r2, [r1]        @ load the lock value
        cmp     r2, r0          @ is the lock free ?
        beq     wait_loop       @ not free...
        swp     r2, r0, [r1]    @ semaphore free so lock it and proceed
        cmp     r2, r0          @ did we succeed ?
        beq     wait_sem        @ no - try again

Regards,
Jean

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Russell King - ARM Linux]

On Thu, Dec 16, 2010 at 12:49:43PM +0100, Jean Pihet wrote:
> Hi,
> 
> The following warning is issued by the compiler (gcc version 4.4.1
> (Sourcery G++ Lite 2010q1-202):
> arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
> for this architecture
> 
> Does this need fixing? If so any hint on how to do it?
> 
> Here is the offending code excerpt:
> 
> wait_sem:
>         mov     r0,#1
>         ldr     r1, sdrc_scratchpad_sem
> wait_loop:
>         ldr     r2, [r1]        @ load the lock value
>         cmp     r2, r0          @ is the lock free ?
>         beq     wait_loop       @ not free...
>         swp     r2, r0, [r1]    @ semaphore free so lock it and proceed
>         cmp     r2, r0          @ did we succeed ?
>         beq     wait_sem        @ no - try again

(untested, as my LDP is useless because of OMAP regressions.)

wait_sem:
	mov	r0, #1
	ldr	r1, sdrc_scratchpad_sem
wait_loop:
	ldrex	r2, [r1]	@ load lock value
	teq	r2, r0		@ is lock free ( != 1)
	beq	wait_loop	@ no, try again
	strex	r2, r0, [r1]	@ try to lock
	teq	r2, #0		@ did store succeed?
	bne	wait_loop	@ no, try again

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Catalin Marinas]

On 16 December 2010 11:56, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Dec 16, 2010 at 12:49:43PM +0100, Jean Pihet wrote:
>> The following warning is issued by the compiler (gcc version 4.4.1
>> (Sourcery G++ Lite 2010q1-202):
>> arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
>> for this architecture
>>
>> Does this need fixing? If so any hint on how to do it?
>>
>> Here is the offending code excerpt:
>>
>> wait_sem:
>> ? ? ? ? mov ? ? r0,#1
>> ? ? ? ? ldr ? ? r1, sdrc_scratchpad_sem
>> wait_loop:
>> ? ? ? ? ldr ? ? r2, [r1] ? ? ? ?@ load the lock value
>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ is the lock free ?
>> ? ? ? ? beq ? ? wait_loop ? ? ? @ not free...
>> ? ? ? ? swp ? ? r2, r0, [r1] ? ?@ semaphore free so lock it and proceed
>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ did we succeed ?
>> ? ? ? ? beq ? ? wait_sem ? ? ? ?@ no - try again
>
> (untested, as my LDP is useless because of OMAP regressions.)
>
> wait_sem:
> ? ? ? ?mov ? ? r0, #1
> ? ? ? ?ldr ? ? r1, sdrc_scratchpad_sem
> wait_loop:
> ? ? ? ?ldrex ? r2, [r1] ? ? ? ?@ load lock value
> ? ? ? ?teq ? ? r2, r0 ? ? ? ? ?@ is lock free ( != 1)
> ? ? ? ?beq ? ? wait_loop ? ? ? @ no, try again
> ? ? ? ?strex ? r2, r0, [r1] ? ?@ try to lock
> ? ? ? ?teq ? ? r2, #0 ? ? ? ? ?@ did store succeed?
> ? ? ? ?bne ? ? wait_loop ? ? ? @ no, try again

I'm not familiar with the OMAP code but I recall they needed swp for
some synchronisation with external processor (DSP). Is this still the
case?

-- 
Catalin

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Jean Pihet]

On Thu, Dec 16, 2010 at 1:47 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On 16 December 2010 11:56, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Thu, Dec 16, 2010 at 12:49:43PM +0100, Jean Pihet wrote:
>>> The following warning is issued by the compiler (gcc version 4.4.1
>>> (Sourcery G++ Lite 2010q1-202):
>>> arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
>>> for this architecture
>>>
>>> Does this need fixing? If so any hint on how to do it?
>>>
>>> Here is the offending code excerpt:
>>>
>>> wait_sem:
>>> ? ? ? ? mov ? ? r0,#1
>>> ? ? ? ? ldr ? ? r1, sdrc_scratchpad_sem
>>> wait_loop:
>>> ? ? ? ? ldr ? ? r2, [r1] ? ? ? ?@ load the lock value
>>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ is the lock free ?
>>> ? ? ? ? beq ? ? wait_loop ? ? ? @ not free...
>>> ? ? ? ? swp ? ? r2, r0, [r1] ? ?@ semaphore free so lock it and proceed
>>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ did we succeed ?
>>> ? ? ? ? beq ? ? wait_sem ? ? ? ?@ no - try again
>>
>> (untested, as my LDP is useless because of OMAP regressions.)
>>
>> wait_sem:
>> ? ? ? ?mov ? ? r0, #1
>> ? ? ? ?ldr ? ? r1, sdrc_scratchpad_sem
>> wait_loop:
>> ? ? ? ?ldrex ? r2, [r1] ? ? ? ?@ load lock value
>> ? ? ? ?teq ? ? r2, r0 ? ? ? ? ?@ is lock free ( != 1)
>> ? ? ? ?beq ? ? wait_loop ? ? ? @ no, try again
>> ? ? ? ?strex ? r2, r0, [r1] ? ?@ try to lock
>> ? ? ? ?teq ? ? r2, #0 ? ? ? ? ?@ did store succeed?
>> ? ? ? ?bne ? ? wait_loop ? ? ? @ no, try again
>
> I'm not familiar with the OMAP code but I recall they needed swp for
> some synchronisation with external processor (DSP). Is this still the
> case?
This code is meant to be used by the new DVFS code which is not merged in yet.

Richard, Karthik,
Can you help on that point?

Thanks,
Jean
>
> --
> Catalin
>

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Will Deacon]

Hi Jean,

> >>> Here is the offending code excerpt:
> >>>
> >>> wait_sem:
> >>>         mov     r0,#1
> >>>         ldr     r1, sdrc_scratchpad_sem
> >>> wait_loop:
> >>>         ldr     r2, [r1]        @ load the lock value
> >>>         cmp     r2, r0          @ is the lock free ?
> >>>         beq     wait_loop       @ not free...
> >>>         swp     r2, r0, [r1]    @ semaphore free so lock it and proceed
> >>>         cmp     r2, r0          @ did we succeed ?
> >>>         beq     wait_sem        @ no - try again
> >>
> >> (untested, as my LDP is useless because of OMAP regressions.)
> >>
> >> wait_sem:
> >>        mov     r0, #1
> >>        ldr     r1, sdrc_scratchpad_sem
> >> wait_loop:
> >>        ldrex   r2, [r1]        @ load lock value
> >>        teq     r2, r0          @ is lock free ( != 1)
> >>        beq     wait_loop       @ no, try again
> >>        strex   r2, r0, [r1]    @ try to lock
> >>        teq     r2, #0          @ did store succeed?
> >>        bne     wait_loop       @ no, try again
> >
> > I'm not familiar with the OMAP code but I recall they needed swp for
> > some synchronisation with external processor (DSP). Is this still the
> > case?
> This code is meant to be used by the new DVFS code which is not merged in yet.

I don't know what you do with this lock held or what the contention
is like, but you probably want a memory barrier immediately after you've
acquired it and another one before you release it.

Will

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Jean Pihet]

Hi Will,

On Thu, Dec 16, 2010 at 6:05 PM, Will Deacon <will.deacon@arm.com> wrote:
> Hi Jean,
>
>> >>> Here is the offending code excerpt:
>> >>>
>> >>> wait_sem:
>> >>> ? ? ? ? mov ? ? r0,#1
>> >>> ? ? ? ? ldr ? ? r1, sdrc_scratchpad_sem
>> >>> wait_loop:
>> >>> ? ? ? ? ldr ? ? r2, [r1] ? ? ? ?@ load the lock value
>> >>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ is the lock free ?
>> >>> ? ? ? ? beq ? ? wait_loop ? ? ? @ not free...
>> >>> ? ? ? ? swp ? ? r2, r0, [r1] ? ?@ semaphore free so lock it and proceed
>> >>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ did we succeed ?
>> >>> ? ? ? ? beq ? ? wait_sem ? ? ? ?@ no - try again
>> >>
>> >> (untested, as my LDP is useless because of OMAP regressions.)
>> >>
>> >> wait_sem:
>> >> ? ? ? ?mov ? ? r0, #1
>> >> ? ? ? ?ldr ? ? r1, sdrc_scratchpad_sem
>> >> wait_loop:
>> >> ? ? ? ?ldrex ? r2, [r1] ? ? ? ?@ load lock value
>> >> ? ? ? ?teq ? ? r2, r0 ? ? ? ? ?@ is lock free ( != 1)
>> >> ? ? ? ?beq ? ? wait_loop ? ? ? @ no, try again
>> >> ? ? ? ?strex ? r2, r0, [r1] ? ?@ try to lock
>> >> ? ? ? ?teq ? ? r2, #0 ? ? ? ? ?@ did store succeed?
>> >> ? ? ? ?bne ? ? wait_loop ? ? ? @ no, try again
>> >
>> > I'm not familiar with the OMAP code but I recall they needed swp for
>> > some synchronisation with external processor (DSP). Is this still the
>> > case?
>> This code is meant to be used by the new DVFS code which is not merged in yet.
>
> I don't know what you do with this lock held or what the contention
> is like, but you probably want a memory barrier immediately after you've
> acquired it and another one before you release it.
OK, thanks for the suggestion.

Since this code is not used at the moment it will be removed.
It shall be added back, fixed and tested later when the API will be in real use.

Thanks,
Jean

>
> Will
>
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Dave Martin]

On Thu, Dec 16, 2010 at 5:16 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> Hi Will,
>
> On Thu, Dec 16, 2010 at 6:05 PM, Will Deacon <will.deacon@arm.com> wrote:
>> Hi Jean,
>>
>>> >>> Here is the offending code excerpt:
>>> >>>
>>> >>> wait_sem:
>>> >>> ? ? ? ? mov ? ? r0,#1
>>> >>> ? ? ? ? ldr ? ? r1, sdrc_scratchpad_sem
>>> >>> wait_loop:
>>> >>> ? ? ? ? ldr ? ? r2, [r1] ? ? ? ?@ load the lock value
>>> >>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ is the lock free ?
>>> >>> ? ? ? ? beq ? ? wait_loop ? ? ? @ not free...
>>> >>> ? ? ? ? swp ? ? r2, r0, [r1] ? ?@ semaphore free so lock it and proceed
>>> >>> ? ? ? ? cmp ? ? r2, r0 ? ? ? ? ?@ did we succeed ?
>>> >>> ? ? ? ? beq ? ? wait_sem ? ? ? ?@ no - try again
>>> >>
>>> >> (untested, as my LDP is useless because of OMAP regressions.)
>>> >>
>>> >> wait_sem:
>>> >> ? ? ? ?mov ? ? r0, #1
>>> >> ? ? ? ?ldr ? ? r1, sdrc_scratchpad_sem
>>> >> wait_loop:
>>> >> ? ? ? ?ldrex ? r2, [r1] ? ? ? ?@ load lock value
>>> >> ? ? ? ?teq ? ? r2, r0 ? ? ? ? ?@ is lock free ( != 1)
>>> >> ? ? ? ?beq ? ? wait_loop ? ? ? @ no, try again
>>> >> ? ? ? ?strex ? r2, r0, [r1] ? ?@ try to lock
>>> >> ? ? ? ?teq ? ? r2, #0 ? ? ? ? ?@ did store succeed?
>>> >> ? ? ? ?bne ? ? wait_loop ? ? ? @ no, try again
>>> >
>>> > I'm not familiar with the OMAP code but I recall they needed swp for
>>> > some synchronisation with external processor (DSP). Is this still the
>>> > case?
>>> This code is meant to be used by the new DVFS code which is not merged in yet.
>>
>> I don't know what you do with this lock held or what the contention
>> is like, but you probably want a memory barrier immediately after you've
>> acquired it and another one before you release it.
> OK, thanks for the suggestion.
>
> Since this code is not used at the moment it will be removed.
> It shall be added back, fixed and tested later when the API will be in real use.

Note that the above bit of code is similar/identical to a bit of code
already present in the OMAP BSP... so this still needs to be
addressed.

See arch/arm/mach-omap2/sleep34xx.S:lock_scratchpad_sem


I encountered the same problem when trying to build this code for
Thumb-2 -- though there it's an error, not a warning since Thumb-2 has
no instruction encoding for SWP at all.

I suspect that an actual atomic swap is needed on the bus to
synchronise safely with some piece of hardware in these cases -- I
don't know whether there's a workaround. Some with knowledge about the
hardware will need to comment.

If the SWP must be used, there are a few options: use ",arch armv5" in
the assembler file; use -march=armv5 for the whole file; or use .long
0xe1012090.  Unfortunately, none of these alternatives is pretty :/

Will is probably correct regarding the need for barriers, also.

Cheers
---Dave

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Russell King - ARM Linux]

On Thu, Dec 16, 2010 at 08:04:41PM +0000, Dave Martin wrote:
> Note that the above bit of code is similar/identical to a bit of code
> already present in the OMAP BSP... so this still needs to be
> addressed.
> 
> See arch/arm/mach-omap2/sleep34xx.S:lock_scratchpad_sem

That's odd.

| The following warning is issued by the compiler (gcc version 4.4.1
| (Sourcery G++ Lite 2010q1-202):
| arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
| for this architecture

It seems we're discussing the same code!

As has been pointed out, and as Jean points out, this code is not called
at the moment, so can be removed to resolve the problem.

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Jean Pihet]

On Thu, Dec 16, 2010 at 9:10 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Thu, Dec 16, 2010 at 08:04:41PM +0000, Dave Martin wrote:
>> Note that the above bit of code is similar/identical to a bit of code
>> already present in the OMAP BSP... so this still needs to be
>> addressed.
>>
>> See arch/arm/mach-omap2/sleep34xx.S:lock_scratchpad_sem
>
> That's odd.
>
> | The following warning is issued by the compiler (gcc version 4.4.1
> | (Sourcery G++ Lite 2010q1-202):
> | arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
> | for this architecture
>
> It seems we're discussing the same code!
>
> As has been pointed out, and as Jean points out, this code is not called
> at the moment, so can be removed to resolve the problem.
>
Exactly! It is actually planned for removal, cf.
http://marc.info/?l=linux-omap&m=129252188012958&w=2

A better solution will be needed at the time the API will be in use.

Thanks,
Jean

OMAP3: Warning: swp{b} use is deprecated for this architecture

[Dave Martin]

Hi,

On Thu, Dec 16, 2010 at 9:44 PM, Jean Pihet <jean.pihet@newoldbits.com> wrote:
> On Thu, Dec 16, 2010 at 9:10 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Thu, Dec 16, 2010 at 08:04:41PM +0000, Dave Martin wrote:
>>> Note that the above bit of code is similar/identical to a bit of code
>>> already present in the OMAP BSP... so this still needs to be
>>> addressed.
>>>
>>> See arch/arm/mach-omap2/sleep34xx.S:lock_scratchpad_sem
>>
>> That's odd.
>>
>> | The following warning is issued by the compiler (gcc version 4.4.1
>> | (Sourcery G++ Lite 2010q1-202):
>> | arch/arm/mach-omap2/sleep34xx.S:87: Warning: swp{b} use is deprecated
>> | for this architecture
>>
>> It seems we're discussing the same code!

Hmmm, guess I didn't look closely enough in the filename from the
original post(!)

>>
>> As has been pointed out, and as Jean points out, this code is not called
>> at the moment, so can be removed to resolve the problem.
>>
> Exactly! It is actually planned for removal, cf.
> http://marc.info/?l=linux-omap&m=129252188012958&w=2

Well, that solves the problem nicely, for now...

Cheers
---Dave

> A better solution will be needed at the time the API will be in use.
>
> Thanks,
> Jean
>