want to clarify powerpc assembly conventions in head.S and entry.S

want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

I'm doing some work in head.S and entry.S, and I just wanted to make 
sure that I had the conventions down.

According to the docs I read, r0 and r3-12 are caller-saves.  They seem 
to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in 
ret_from_except() (entry.S).  Thus, if I add code in entry.S I should be 
able to use any of those registers, without having to worry about 
restoring them myself--correct?

Also, I'm a bit confused about the three instances of the following line 
in entry.S:

	stwcx.	r0,0,r1			/* to clear the reservation */

I don't see the corresponding lwarx instruction.  What reservation is it 
referring to?

Thanks,

Chris

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Benjamin Herrenschmidt]

On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:
> I'm doing some work in head.S and entry.S, and I just wanted to make
> sure that I had the conventions down.
> 
> According to the docs I read, r0 and r3-12 are caller-saves.  They seem
> to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
> ret_from_except() (entry.S).  Thus, if I add code in entry.S I should be
> able to use any of those registers, without having to worry about
> restoring them myself--correct?

Yes. For interrupts or faults that's right. Syscalls are a bit special
though.
 
> Also, I'm a bit confused about the three instances of the following line
> in entry.S:
> 
> 	stwcx.	r0,0,r1			/* to clear the reservation */
> 
> I don't see the corresponding lwarx instruction.  What reservation is it
> referring to?

This is to clear any possible pending reservation if any. The problem is
that the reservation mecanism only works accross multiple CPUs. A normal
store at an address covered by a reservation on the same CPU will not break
the reservation. Thus, to protect from that, any interrupt or exception
makes sure to return to the normal code flow with any pending reservation
cleared.

Ben.

Re: want to clarify powerpc assembly conventions in head.S andentry.S

[Benjamin Herrenschmidt]

On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:
> I'm doing some work in head.S and entry.S, and I just wanted to make
> sure that I had the conventions down.
>
> According to the docs I read, r0 and r3-12 are caller-saves.  They seem
> to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
> ret_from_except() (entry.S).  Thus, if I add code in entry.S I should be
> able to use any of those registers, without having to worry about
> restoring them myself--correct?

Yes. For interrupts or faults that's right. Syscalls are a bit special
though.

> Also, I'm a bit confused about the three instances of the following line
> in entry.S:
>
> 	stwcx.	r0,0,r1			/* to clear the reservation */
>
> I don't see the corresponding lwarx instruction.  What reservation is it
> referring to?

This is to clear any possible pending reservation if any. The problem is
that the reservation mecanism only works accross multiple CPUs. A normal
store at an address covered by a reservation on the same CPU will not break
the reservation. Thus, to protect from that, any interrupt or exception
makes sure to return to the normal code flow with any pending reservation
cleared.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

Benjamin Herrenschmidt wrote:
> On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:

>>According to the docs I read, r0 and r3-12 are caller-saves.  They seem
>>to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
>>ret_from_except() (entry.S).  Thus, if I add code in entry.S I should be
>>able to use any of those registers, without having to worry about
>>restoring them myself--correct?
> 
> Yes. For interrupts or faults that's right. Syscalls are a bit special
> though.

You knew this was coming...  What's special about syscalls?  There's the 
r3 thing, but other than that...

Thanks for your help with this stuff.  As I've been slowly wrapping my 
head around it I've been continuously wishing for some kind of design 
rules document describing the various paths through the assembly code, 
along with register conventions and such.  I eventually did find the 
conventions linked off the penguinppc website, but it was not obvious 
from just reading the code or the ppc stuff in the Documentation directory.

Chris

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Benjamin Herrenschmidt]

> You knew this was coming...  What's special about syscalls?  There's the 
> r3 thing, but other than that...

The whole codepath is a bit different, there's the syscall trace,
we can avoid saving much more registers are syscalls are function
calls and so can clobber the non volatiles, etc...

> Thanks for your help with this stuff.  As I've been slowly wrapping my 
> head around it I've been continuously wishing for some kind of design 
> rules document describing the various paths through the assembly code, 
> along with register conventions and such.  I eventually did find the 
> conventions linked off the penguinppc website, but it was not obvious 
> from just reading the code or the ppc stuff in the Documentation directory.
> 
> Chris
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

Benjamin Herrenschmidt wrote:
> On Sat, 2004-04-10 at 17:41, Chris Friesen wrote:

>>According to the docs I read, r0 and r3-12 are caller-saves.  They seem
>>to be saved in EXCEPTION_PROLOG_2 (head.S) and restored in
>>ret_from_except() (entry.S).  Thus, if I add code in entry.S I should be
>>able to use any of those registers, without having to worry about
>>restoring them myself--correct?
>
> Yes. For interrupts or faults that's right. Syscalls are a bit special
> though.

You knew this was coming...  What's special about syscalls?  There's the
r3 thing, but other than that...

Thanks for your help with this stuff.  As I've been slowly wrapping my
head around it I've been continuously wishing for some kind of design
rules document describing the various paths through the assembly code,
along with register conventions and such.  I eventually did find the
conventions linked off the penguinppc website, but it was not obvious
from just reading the code or the ppc stuff in the Documentation directory.

Chris

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.Sand entry.S

[Benjamin Herrenschmidt]

> You knew this was coming...  What's special about syscalls?  There's the
> r3 thing, but other than that...

The whole codepath is a bit different, there's the syscall trace,
we can avoid saving much more registers are syscalls are function
calls and so can clobber the non volatiles, etc...

> Thanks for your help with this stuff.  As I've been slowly wrapping my
> head around it I've been continuously wishing for some kind of design
> rules document describing the various paths through the assembly code,
> along with register conventions and such.  I eventually did find the
> conventions linked off the penguinppc website, but it was not obvious
> from just reading the code or the ppc stuff in the Documentation directory.
>
> Chris
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

Benjamin Herrenschmidt wrote:
>>You knew this was coming...  What's special about syscalls?  There's the 
>>r3 thing, but other than that...
> 
> The whole codepath is a bit different, there's the syscall trace,
> we can avoid saving much more registers are syscalls are function
> calls and so can clobber the non volatiles, etc...

It appears that we always enter the kernel via "transfer_to_handler", 
and return via "ret_from_except".  Is this true? (I'm running on at 
least a 74xx chip.)

I want to insert two new bits of code, one that gets called before the 
exception handler when we drop from userspace to kernelspace, and one as 
late as possible before going back to userspace.  I need to catch 
syscalls, interrupts, exceptions, everything.

The entry one I planned on putting in "transfer_to_handler", just before 
"addi   r11,r1,STACK_FRAME_OVERHEAD".

I was planning on putting the exit one just after the "restore_user" 
label.  Will this catch all possible returns to userspace?

Thanks,

Chris

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

Benjamin Herrenschmidt wrote:
>>You knew this was coming...  What's special about syscalls?  There's the
>>r3 thing, but other than that...
>
> The whole codepath is a bit different, there's the syscall trace,
> we can avoid saving much more registers are syscalls are function
> calls and so can clobber the non volatiles, etc...

It appears that we always enter the kernel via "transfer_to_handler",
and return via "ret_from_except".  Is this true? (I'm running on at
least a 74xx chip.)

I want to insert two new bits of code, one that gets called before the
exception handler when we drop from userspace to kernelspace, and one as
late as possible before going back to userspace.  I need to catch
syscalls, interrupts, exceptions, everything.

The entry one I planned on putting in "transfer_to_handler", just before
"addi   r11,r1,STACK_FRAME_OVERHEAD".

I was planning on putting the exit one just after the "restore_user"
label.  Will this catch all possible returns to userspace?

Thanks,

Chris

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Benjamin Herrenschmidt]

On Tue, 2004-04-13 at 00:31, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>You knew this was coming...  What's special about syscalls?  There's the
> >>r3 thing, but other than that...
> >
> > The whole codepath is a bit different, there's the syscall trace,
> > we can avoid saving much more registers are syscalls are function
> > calls and so can clobber the non volatiles, etc...
> 
> It appears that we always enter the kernel via "transfer_to_handler",
> and return via "ret_from_except".  Is this true? (I'm running on at
> least a 74xx chip.)

ret_from_syscall for syscalls, hash_page also has a different
return to userland path, and load_up_{fpu,altivec} have their own
retturn path.
On ppc32 currently, the entry is almost always the same except for
hash_page and load_up_{fpu,altivec}

> I want to insert two new bits of code, one that gets called before the
> exception handler when we drop from userspace to kernelspace, and one as
> late as possible before going back to userspace.  I need to catch
> syscalls, interrupts, exceptions, everything.
> 
> The entry one I planned on putting in "transfer_to_handler", just before
> "addi   r11,r1,STACK_FRAME_OVERHEAD".
> 
> I was planning on putting the exit one just after the "restore_user"
> label.  Will this catch all possible returns to userspace?

No.

Ben.

Re: want to clarify powerpc assembly conventions inhead.S and entry.S

[Benjamin Herrenschmidt]

On Tue, 2004-04-13 at 00:31, Chris Friesen wrote:
> Benjamin Herrenschmidt wrote:
> >>You knew this was coming...  What's special about syscalls?  There's the
> >>r3 thing, but other than that...
> >
> > The whole codepath is a bit different, there's the syscall trace,
> > we can avoid saving much more registers are syscalls are function
> > calls and so can clobber the non volatiles, etc...
>
> It appears that we always enter the kernel via "transfer_to_handler",
> and return via "ret_from_except".  Is this true? (I'm running on at
> least a 74xx chip.)

ret_from_syscall for syscalls, hash_page also has a different
return to userland path, and load_up_{fpu,altivec} have their own
retturn path.
On ppc32 currently, the entry is almost always the same except for
hash_page and load_up_{fpu,altivec}

> I want to insert two new bits of code, one that gets called before the
> exception handler when we drop from userspace to kernelspace, and one as
> late as possible before going back to userspace.  I need to catch
> syscalls, interrupts, exceptions, everything.
>
> The entry one I planned on putting in "transfer_to_handler", just before
> "addi   r11,r1,STACK_FRAME_OVERHEAD".
>
> I was planning on putting the exit one just after the "restore_user"
> label.  Will this catch all possible returns to userspace?

No.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

Benjamin Herrenschmidt wrote:

> ret_from_syscall for syscalls, hash_page also has a different
> return to userland path, and load_up_{fpu,altivec} have their own
> retturn path.
> On ppc32 currently, the entry is almost always the same except for
> hash_page and load_up_{fpu,altivec}

Thanks, that's exactly the information I needed.

Chris

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Chris Friesen]

Benjamin Herrenschmidt wrote:

> ret_from_syscall for syscalls, hash_page also has a different
> return to userland path, and load_up_{fpu,altivec} have their own
> retturn path.
> On ppc32 currently, the entry is almost always the same except for
> hash_page and load_up_{fpu,altivec}

Thanks, that's exactly the information I needed.

Chris

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Segher Boessenkool]

>> 	stwcx.	r0,0,r1			/* to clear the reservation */
>>
>> I don't see the corresponding lwarx instruction.  What reservation is 
>> it
>> referring to?
>
> This is to clear any possible pending reservation if any. The problem 
> is
> that the reservation mecanism only works accross multiple CPUs. A 
> normal
> store at an address covered by a reservation on the same CPU will not 
> break
> the reservation. Thus, to protect from that, any interrupt or exception
> makes sure to return to the normal code flow with any pending 
> reservation
> cleared.

Worse, it is allowed for a PowerPC implementation to not check if 
stwcx. and
stdcx. refer to the same address as the preceding lwarx or ldarx .  So, 
a store
conditional insn can succeed because the cpu holds some *other* 
reservation.
Therefore, the kernel has to clear any reservation that might not have 
been
generated by the user code it is returning to.


Segher

Re: want to clarify powerpc assembly conventions in head.S and entry.S

[Segher Boessenkool]

>> 	stwcx.	r0,0,r1			/* to clear the reservation */
>>
>> I don't see the corresponding lwarx instruction.  What reservation is
>> it
>> referring to?
>
> This is to clear any possible pending reservation if any. The problem
> is
> that the reservation mecanism only works accross multiple CPUs. A
> normal
> store at an address covered by a reservation on the same CPU will not
> break
> the reservation. Thus, to protect from that, any interrupt or exception
> makes sure to return to the normal code flow with any pending
> reservation
> cleared.

Worse, it is allowed for a PowerPC implementation to not check if
stwcx. and
stdcx. refer to the same address as the preceding lwarx or ldarx .  So,
a store
conditional insn can succeed because the cpu holds some *other*
reservation.
Therefore, the kernel has to clear any reservation that might not have
been
generated by the user code it is returning to.


Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Any hints on custom keyboard driver?

[Song Sam]

Hi,

I am in a trouble of coding a custom keyboard driver
under 2.4.18.

My custom keyboard scheme is as following:

          MPC823  IP_B0  IP_B1  IP_B2   IP_B3  IP_B4-7
Parallel Port
     PD0            1      q       a      z     ...
     PD1            2      w       s      x     ...
     PD2            3      e       d      c     ...
     PD3            4      r       f      v     ...
     PD4            ...    ...     ...   ...    ...
     ...

My Puzzles:
1. Should I use input.o as interactive interface to
communicate with kernel & user space for convenience?
Otherwise,I need to code it as a normal char device
drvier.I have finished to make PCMCIA and Parallel
port create a character by now.

2. Is there any clue on how to code a standard input
driver?Or any reference in this aspect?

Thanks a million in advance for any input!!!

Sam

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Any hints on custom keyboard driver?

[Brad Boyer]

On Thu, Apr 15, 2004 at 11:24:53PM +0800, Song Sam wrote:
> My Puzzles:
> 1. Should I use input.o as interactive interface to
> communicate with kernel & user space for convenience?

If you want to use this keyboard for your console, then the easiest
way would be to create an input layer driver. I think USB and ADB
are the only keyboard drivers using the input layer in 2.4, but
just about everything is using it in 2.6.

> 2. Is there any clue on how to code a standard input
> driver?Or any reference in this aspect?

There is some documentation in the kernel source. Take a look at
the stuff in Documentation/input/.

	Brad Boyer
	flar@allandria.com


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Any hints on custom keyboard driver?

[Song Sam]

Brad Boyer <flar@allandria.com> wrote:
> > 1. Should I use input.o as interactive interface to communicate with
> > kernel & user space for convenience?

> If you want to use this keyboard for your console, then the easiest
> way would be to create an input layer driver.

Thanks for your hints.So,the data flow related my
custom keyboard driver module could be like this:

My_custom_keyboard device -> mykeyboard.o -> input.o

-> keybdev.o -> LINUX kernel

> I think USB and ADB are the only keyboard drivers using the input
> layer in 2.4, but just about everything is using it in 2.6.

That's also a puzzle for me.Use input layer for my
custom keyboard in 2.4 or not and how?Could I take 2.6
PC keyboard driver as a reference for my custom
keyboard driver?

> > 2. Is there any clue on how to code a standard input driver?Or any
> > reference in this aspect?

> There is some documentation in the kernel source. Take a look at the
> stuff in Documentation/input/.

I have studied some stuff in Documentation/input
several days but still have some troubles for these
simplified demo.Also,I searched "linux keyboard
driver" in google but no luck.Anyway,this is my first
time to code a custom driver.I hope this one isn't
hard more than I can chew.

Thanks a lot for your nice advice!

Sam

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/