• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 100 subscribers
  • Views 1496 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TCI6630K2L: What is the preferred way to post a SW interrupt from DSP to ARM on K2L?

Atmeg
Intellectual 870 points
Part Number: TCI6630K2L
Other Parts Discussed in Thread: SYSBIOS

What are the basic steps to configure ISR from Linux driver side and from sysbios side?

  • 0
    TI__Guru**** 161600 points
    Hi Atmeg,

    From linux side, you should correctly set the dts node. For reference see the keystone-k2l.dtsi file. Look at the interrupt-parent & interrupts parameters in the device tree nodes, for example see the dsp0 node:
    dsp0: dsp0 {
    compatible = "ti,k2l-dsp";
    reg = <0x10800000 0x00100000>,
    <0x10e00000 0x00008000>,
    <0x10f00000 0x00008000>;
    reg-names = "l2sram", "l1pram", "l1dram";
    clocks = <&clkgem0>;
    ti,syscon-dev = <&devctrl 0x844>;
    resets = <&pscrst 0>;
    interrupt-parent = <&kirq0>;
    interrupts = <0 8>;
    interrupt-names = "vring", "exception";
    kick-gpio = <&dspgpio0 27 0>;
    };

    If you'd like to communicate between the dsp & arm, you'll need to use the IPC module.

    I am also looping the RTOS team to elaborate if there are any specific settings from the sysbios side.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 870 points

    Thank you for fast reply,

    I change dts file and register IRQ in linux driver with request_irq() call. I see my new IRQ at /proc/interrupts

    Is it enought for linux-side configuration?

  • 0 in reply to Atmeg
    TI__Guru**** 161600 points
    Hi Atmeg,

    Yes, this indicates that you've configured the IRQ correctly.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Intellectual 870 points
    Ok,
    dsp side left now...
  • 0 in reply to Atmeg
    TI__Genius 12805 points
    You ask how to send an interrupt from the DSP to the ARM or how to configure the DSP to accept interrupt from the ARM?

    The second question appeared many times in e2e, do search on how to configure interrupt C66

    For the first question there are multiple ways. Look at www.ti.com/.../66ak2l06.pdf
    You can set the DSP to manipulate one of the GPIO and connect it to the ARM (see table 7-23 of the document)
    Or you can use the IPC registers - look at table 7-25 lines 471 to 474.
    There are other ways as well.

    Does it answer the right question?

    Ran
  • 0 in reply to ran35366
    Intellectual 870 points

    Thank you!

    I write to IPCGR8 register with bit 16 in SRCSx and IPCG set to 1 on DSP side and catch my irq 528=512+16 on Linux.

  • 0 in reply to Atmeg
    Intellectual 755 points
    Hi Atmeg

    Glad to see you have make it work !

    I am also in trouble with these stuff. Can you share your dts/driver file for reference?

    Thanks !

    striker
  • 0 in reply to Yordan Kovachev
    Intellectual 755 points
    Hi Yordan

    I am still a little confused about this - As far as I know, when I cat /proc/interrupts in linux . I got information like

    520: 0 0 keystone-ipc-irq 2620844.dsp0
    521: 0 0 keystone-ipc-irq 2620848.dsp1
    522: 0 0 keystone-ipc-irq 262084C.dsp2
    523: 0 0 keystone-ipc-irq 2620850.dsp3

    Q1: Are these four lines means that 4-irqs are ready to catch IPC interrupts from DSP side?

    Q2: If Q1 is true why we need to add our own code in dts file or driver, is that just used to catch intc in user space?

    Q3: I tried to write to IPCGR8 in DSP core0 , but failed to see increment of number in line-520. why is that?

    Any advice is apprecaited !

    Thanks!
  • 0 in reply to striker qian
    Intellectual 870 points

    Hi striker

    dts modifications is:

            dsp0 {
            ...
                interrupts = <0x8 0x0 0x0 0x0 0x18 0x0>;
            ...
            };

            dsp1 {
            ...
                interrupts = <0x9 0x0 0x1 0x0 0x19 0x0>;
            ...    
            };

    and so on.

    Driver code, that configures irq:

        if (request_irq(<irq number>, your_irqhandler, 0, <irq description string>, NULL)) {
            printk(KERN_ERR "error descriptio\n");
            ....
        }

  • 0 in reply to Atmeg
    Intellectual 755 points

    Thanks, Atmeg

    However I am also curious on some questions - forgive me of that I'm a newbee on device tree stuff.

    1)  interrupts = <0x8 0x0 0x0 0x0 0x18 0x0>  -- what is the last two elements stand for ? Hoestly that the number of interrupts elements is 4 or 6 is also confusing me , I only see #interrupt-cells = <2> in

    branch ipcirq0 of keystone.dtsi. 

    2) your IRQ number is 512+16 = 528 - what is the meaning of 512 and where did you get this number ? It looks like something of basic ipc-irq number.

    3) request_irq(<irq number> , using what function do you get the irq number or did you just directly use 528?  There are totally 28bits which can trigger irq- does it mean 28 request_irq function are needed if I want to capture all of them?

    Regards.

  • 0 in reply to striker qian
    Intellectual 870 points

    1) #interrupt-cells = <2> means 2 fields are used for each irq definition. I.e. 4 fields for 2 irqs, 6 fields for 3 irqs. First field defines irq number. I don't know what means the second (could anybody explain what is it?)

    2) About 512 offset, I obtain this number by comparing cat /proc/interrupts and irq number from device tree. May be this number is defined somewhere in the documents, but I did not found.

    3) I use platform_get_irq(platform_device, 2) to obtain the irq number. It returns 528 and so on numbers, it's not nessesary to know or define this 512 offset. 0 and 1 platform irqs is in use by remoteproc and 2 I use for me.

    In remoteproc_user.c:

        uproc->irq_ctl    = platform_get_irq(pdev, 0);
        uproc->irq_ring    = platform_get_irq(pdev, 1);
        rproc->trace_irq = platform_get_irq(pdev, 2);  <-- added

    trace_irq is a field I added to the rproc structure to pass irq to the driver

  • 0 in reply to Atmeg
    Intellectual 755 points
    Thanks, Atmeg

    I got my irqs too. Thanks for your info and that really helps .

    Here are some tips I summarize, Just FYI and anyone else who has the same confusion.

    I guess the first element in interrupts <8 0 0 0 24 0> of k2l.dtsi file is the logic interrupt number index for ipcirq which confirms to the definiton in irq-keystone-ipc.c . 8 means the BIT12 (4+8) of IPCGR8 register and likewise the 24 stands for BIT28. The second element I suppse stands for Irq type whose definition can be found in include/linux/irq.h and Documentation/devicetree/binds/interrupt-controller/interrupts.txt.

    Bisides the interrupts you requested, we can see in the kernel entering "cat /proc/interrupts" there are already 4 prebuit interrupts enabled done by ti :
    520: 0 0 keystone-ipc-irq 2620844.dsp0
    521: 0 0 keystone-ipc-irq 2620848.dsp1
    522: 0 0 keystone-ipc-irq 262084C.dsp2
    523: 0 0 keystone-ipc-irq 2620850.dsp3

    We could triggle any of them by sending 1 | (1<<(4+8) ) in any of the four dsp cores.

    Regards!

    Striker