Re: Problem with decrementer interrupt
Sumedh,
I've just noticed you are using the bla instruction, which use absolute
target address: are you sure the C code gets even be executed ?
I don't know how the compiler successfully assemble your code because the
binary is supposed to be position independant code (PIC): you should rather
use bl instruction (relative branch).
--
sj
2009/2/23 sumedh tirodkar sumedhtirod...@gmail.com
I have initialised to stack pointer(r1) properly...actually...i went
thru the object dump...bt when i juz use
bla function_name_handler
the link register is not getting pushed on to the stack in the prolog
of that function...so the stack is basically not coming into the
picture...
@IRQ originator, that doesn't seem to be a problem...
The only thing that i am able to think of is that when i do a bla,
the return address is not getting stored in link register...and i m
not able to figure out why...
Regards,
Sumedh
On Mon, Feb 23, 2009 at 11:03 PM, sjoy...@wanadoo.fr sjoy...@wanadoo.fr
wrote:
Hi Sumedh,
You may check the context in which your CPU in running the C code from
interrupt context (ie stack pointer (r1), kernel locks disabling
rescheduling etc..) and double check the IRQ originator (the decrementer)
is
acknowlegded somewhere your handler before enabling back interrupts, else
your handler gets fired.
--
sj
2009/2/23 sumedh tirodkar sumedhtirod...@gmail.com
Alright...I am trying to develop a system of my own..
Consider that i am not using any linux kernel...I m writing some
program right from scratch.
The major steps that i have taken are...
1. Started with a assembly file...
2. Have relocated the interrupt handlers to there respective
positions...The interrupt handlers are written in assembly language...
3. Initialised Decrementer register to get an interrupt after some
interval...
4. Jump to some function using
bl function_name_main
function_name_main which will have a infinite while loop..
This works fine i.e. the interrupts(decrementer interrupt to be more
specific) work fine...I have initialised serial port to get the
output...
Now, the problem that i am facing
If in interrupt handler of the decrementer, i make a call to some C
function in some other C file...using the follwing statement...
Dec_handler: /* I have relocated this to interrupt vector address of
decrementer interrupt*/
/*code to print using serial port*/
bla function_name_handler /*code to call some function in C file*/
/*code to print using serial port---but i m never able to see this
output*/
RFI
This starts creating a problem...somehow we dont return to this code
after the end of the function_name_handler...
Consider the following code for the function_name_handler:
void function_name_handler(void)
{
/*Some action*/
}
So, if its possible for anyone to help me with this...please reply...
Regards,
Sumedh
On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner mgess...@gmail.com
wrote:
On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
sumedhtirod...@gmail.com
wrote:
I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC...
What I said earlier was: You need to tell people what cpu you're
using,
what
linux kernel, etc etc etc.
Fine, we know the CPU. What kernel are you using? Is it ancient?
I doubt the information below is going to be useful...
I am using
bla function_name
from the assembly code to call the function in C file...This i am
doing from interrupt handler of the decrementer...
If any more details are required, please let me know...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
--
Sylvain JOYEAU
Freelance Engineer
Software RT-OS RD
sylvain.joy...@gmail.com
Tél: +33-(0)667 477 052
A good idea is one side of the coin. The other side is the practical
usefulness. J. Liedke.
--
--
Sylvain JOYEAU
Freelance Engineer
Software RT-OS RD
sylvain.joy...@gmail.com
Tél: +33-(0)667 477 052
A good idea is one side of the coin. The other side is the practical
usefulness. J. Liedke.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problem with decrementer interrupt
Hi Sumedh,
You may check the context in which your CPU in running the C code from
interrupt context (ie stack pointer (r1), kernel locks disabling
rescheduling etc..) and double check the IRQ originator (the decrementer) is
acknowlegded somewhere your handler before enabling back interrupts, else
your handler gets fired.
--
sj
2009/2/23 sumedh tirodkar sumedhtirod...@gmail.com
Alright...I am trying to develop a system of my own..
Consider that i am not using any linux kernel...I m writing some
program right from scratch.
The major steps that i have taken are...
1. Started with a assembly file...
2. Have relocated the interrupt handlers to there respective
positions...The interrupt handlers are written in assembly language...
3. Initialised Decrementer register to get an interrupt after some
interval...
4. Jump to some function using
bl function_name_main
function_name_main which will have a infinite while loop..
This works fine i.e. the interrupts(decrementer interrupt to be more
specific) work fine...I have initialised serial port to get the
output...
Now, the problem that i am facing
If in interrupt handler of the decrementer, i make a call to some C
function in some other C file...using the follwing statement...
Dec_handler: /* I have relocated this to interrupt vector address of
decrementer interrupt*/
/*code to print using serial port*/
bla function_name_handler /*code to call some function in C file*/
/*code to print using serial port---but i m never able to see this
output*/
RFI
This starts creating a problem...somehow we dont return to this code
after the end of the function_name_handler...
Consider the following code for the function_name_handler:
void function_name_handler(void)
{
/*Some action*/
}
So, if its possible for anyone to help me with this...please reply...
Regards,
Sumedh
On Mon, Feb 23, 2009 at 8:18 PM, Matt Gessner mgess...@gmail.com wrote:
On Mon, Feb 23, 2009 at 8:03 AM, sumedh tirodkar
sumedhtirod...@gmail.com
wrote:
I am using PowerPC 7447A...I am trying to port SA-RTL on PowerPC...
What I said earlier was: You need to tell people what cpu you're using,
what
linux kernel, etc etc etc.
Fine, we know the CPU. What kernel are you using? Is it ancient?
I doubt the information below is going to be useful...
I am using
bla function_name
from the assembly code to call the function in C file...This i am
doing from interrupt handler of the decrementer...
If any more details are required, please let me know...
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
--
Sylvain JOYEAU
Freelance Engineer
Software RT-OS RD
sylvain.joy...@gmail.com
Tél: +33-(0)667 477 052
A good idea is one side of the coin. The other side is the practical
usefulness. J. Liedke.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Gianfar tx-babbling-errors
Hi Scott, Your issue may come from data setup (or corruption) instead of code path: babbling error may occurs when a TSEC TX descriptor hasn't its last frame bit set or when the data length is greated than max frame length. -- sj 2009/2/19 Scott Coulter scott.coul...@cyclone.com Kumar, can't think of any. How about adding a BUG_ON() in the tx path to see if the buffer size MTU and re-run your tests. So, here are the checks I've tried in gfar_start_xmit(): BUG_ON(skb-len DEFAULT_RX_BUFFER_SIZE) BUG_ON(skb-len priv-regs-maxfrm) Neither produces a bug check yet ethtool reports non-zero tx-babbling-errors. The last check appears to be the definition of tx-babbling-errors. Is there a transmit path that I have missed? Scott ___ Scott N. Coulter Senior Software Engineer Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coul...@cyclone.com U.S.A.Web:http://www.cyclone.com ___ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- -- Sylvain JOYEAU Freelance Engineer Software RT-OS RD sylvain.joy...@gmail.com Tél: +33-(0)667 477 052 A good idea is one side of the coin. The other side is the practical usefulness. J. Liedke. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: When do i need to allocate DMA buffer
Hi Wael, 1. The DMA engine source and destination registers are based on physical memory addresses, whatever is the bus connected on, thus you need to provide it physical addresses. It looks like you are a bit confused about the terminology DMA buffer: a DMA buffer is either the source and/or destination buffer, but not a intermediate buffer that you could bypass. Perhaps anybody speaking english more fluently can explain that better than me. 2. Know nothing about Linux DMA API, but more thant a bit about MPC8555 DMA, and I can say it's quite easy to program, directly (through DMA registers) if your application doesn't require portability across platforms. AFAIK, the better way to allocate source and/or destination RAM buffer in the kernel side is dma_alloc_coherent(): that's one seems rather portable ! Best regards. -- sj 2009/1/12 wael showair showair2...@yahoo.com: Hi All, i have MPC8555 processor, also i have linux-kernel 2.6.19-rc5 on my board.i want to use the DMA on my board, just a simple example is enough for me but during my reading on how to use the DMA i have some questions: 1. The DMA buffer is always needed for all kind of buses or not? (I think this is valid in the ISA bus but not in the PCI bus, plz correct me if i m wrong?) Note that my target is to transfer data from memory location to another memory location it will be an overhead if i copy the data from the src to the DMA buffer then from the DMA buffer to the Destination. isn't there any other way to avoid using that DMA buffer to copy data from src to dest directly? i read the documentation of my board it tells me that it contain DMA engine which is capable of transferring blocks of data from any legal address range to any other legal address range. 2. i have read DMA-API.txt in the linux Documentation folder but i m little confused about the APIs that exist in this file. Actually, it is stated in this file the following: This document describes the DMA API.This API is split into two pieces. Part I describes the API and the corresponding pci_ API. so if the DMA controller is connected to the PCI bus, am i obligated to use the pci_API for any other case (like ISA bus or any other bus types) shall i use this generic API? also what r the benefits of these APIs over the normal kmalloc? specially that i have read the following section in the DMA-mapping.txt: If you acquired your memory via the page allocator (i.e. __get_free_page*()) or the generic memory allocators (i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from that memory using the addresses returned from those routines. thanks in advance for ur help -- View this message in context: http://www.nabble.com/When-do-i-need-to-allocate-DMA-buffer-tp21413193p21413193.html Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- -- Sylvain JOYEAU Freelance Engineer Software RT-OS RD sylvain.joy...@gmail.com A good idea is one side of the coin. The other side is the practical usefulness. J. Liedke. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
