There seems to be an error in the calculation of the GPIOMUX interrupt router source index in the examples

Hi Philip,

Sorry for the delay, I'm looking at this issue starting today. I'll get back with you shortly.

Regards,
Frank

Hi Philip,

No need for apologies. I'm glad you were able to resolve the issue.

I recently worked on another e2e thread concerned with GPIO interrupt example and GPIO interrupt in general. I gather you've figured all this out by now, but I'll share this thread just in case it might be useful to you:

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1068969/lp-am243-gpio-interrupt-config

Regards,
Frank

Hello Frank,
thank you for pointing me to that post.
As you already guessed,  the stuff you explained there was already clear to me.
But nevertheless, the thought counts.


Best regards

Philip.

Hi Philip,

I also don't know how to de-select "this resolves my issue". It appears I don't have that ability from my e2e interface.

My understanding is the documentation isn't clear about different Sciclient RM API functions for configuring the GPIO Interrupt Router (and the Interrupt Aggregator). Please correct me if I'm mistaken. I've reopened this thread under that assumption.

Specifically, you need clear documentation concerning the tisci_msg_rm_irq_set_req src_index parameter (defined in source\drivers\sciclient\include\tisci\rm\tisci_rm_irq.h), and its usage in the Sciclient_rmIrqSet() function (defined in source/drivers/sciclient/include/sciclient_rm.h).

I'm reviewing your questions and concerns, and will get back with you shortly.

Regards,
Frank

Philip,

Philip Schröder said:

Sciclient_rmIrqIf in drivers/sciclient/soc/am64x_am243x/sciclient_irq_rm.c, line 202ff.

I should have asked this earlier, but what does the 'ff' indicate at the end of the line number? Do you mean line 202? I can't find a comment on line 202. I looked in sciclient_irq_rm.c for MCU+SDK 08_01_00_36 & 08_02_00_12. Can you please share the comment itself?

Philip Schröder said:

tables concerning IR input index to source index

Philip Schröder said:

tables mapping IR output index to destination index

For example, these tables, correct?

• https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#main-gpiomux-introuter0-interrupt-router-input-sources
• https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#main-gpiomux-introuter0-interrupt-router-output-destinations

Regards,
Frank

Hi Philip,

I agree with you concerning a need for more comments in the code. However, I don't think it should be necessary to review the Sciclient code to understand how to use the API. There are clearly mistakes and gaps in the Sciclient/TISCI/SYSFW documentation.

I performed some brute-force experiments using Sciclient_rmIrqSet() with different combinations of the request {src_id, src_index, dst_host_irq} parameters. I've shared the results in the table below.

This suggests to me that the information in (main-gpiomux-introuter0-interrupt-router-input-sources) is incorrect.

If the table was updated as follows, I believe it would be correct:

This matches the results of the experiments, as well as the information contained in sciclient_irq_rm.c. The src_index value for the Sciclient_rmIrqSet() should then be set according to the values in the "Source Index" column in the table. Note this update removes duplicate "Source Index" values in the table.

I have a few more observations concerning this table.

Looking at the TRM, Figure 12-57. GPIO Integration, I see:

• GPIO_0_INT[0:86] → MAIN_GPIO_INTRTR_IN_[0:86]
• GPIO_0_BANK[0:5]_INT  → MAIN_GPIO_INTRTR_IN_[190:195]
• GPIO_1_INT[0:87] → MAIN_GPIO_INTRTR_IN_[90:177]
• GPIO_1_BANK[0:5]_INT → MAIN_GPIO_INTRTR_IN_[180:185]

The values in "IR Input Index" map to GPIOMUX_INTRTR0 input numbers. There are some exceptions I don't understand:

• There are "IR Input Index" values 87,88,89 for GPIO0, and values 178,179 for GPIO1. These should probably be listed as "Not Connected".
• "IR Input Index" 186-189 should be listed as "Not Connected"
• "IR Input Index" 196-198 should be listed as "Not Connected".

I am reviewing these findings with the SW Dev team. I'll keep you posted.

In the meantime, can you please let me know if this helps?

Regards,
Frank

Hello Frank, sorry, I thought ff is common knowledge, maybe I am wrong here.

https://www.yourdictionary.com/ff

When I write <line number>ff I mean "Starting this line and then the following ones".
I have yet to look at the rest of your answer though.


Best regards

Philip.

Hello Frank, thank you for taking the time to review and test the code.
Concerning your question what tables I am talking about.
Right, on this page

software-dl.ti.com/.../interrupt_cfg.html

there are several tables.
Some of them are mapping interrupt router input index to source index, like this:



and then there are those which map IR output index to destination index, like this:



And as I understand it, the interrupt routing works like this:

...


Best regards

Philip.

Hello Frank,
I beg your pardon for writing several answers as I go through your points step by step.

Frank Livingston said:

I agree with you concerning a need for more comments in the code. However, I don't think it should be necessary to review the Sciclient code to understand how to use the API. There are clearly mistakes and gaps in the Sciclient/TISCI/SYSFW documentation.

Well, I need to be able to tell the users of my Interrupt classes where to obtain the configuration parameters like those src and dest index numbers and the device IDs.
And I need them to choose the right ones on their own. And it is quite hard to explain it to them when the documentation includes conflicting information.

Also, I understood the resource ranges like I could choose an interrupt source and for that source I could let the interrupt router tell me which output lines I can choose from to route the interrupt signal for that source. Then I found out from your example, that what I was really getting was only the whole range of the interrupt router which was not subdivided by those destination interfaces. I could provide a host ID, but it is not clear what that would achieve.
my understanding is for GPIOs that I would get only the output index numbers for AM64X_DEV_R5FSS0_CORE0 or only those for AM64X_DEV_R5FSS0_CORE1 for instance.

In many tables I find columns with stuff that is nowhere explained (or I didn't find anything about it at least), like in the interrupt router example it says "source name"
 but without telling that it is the name of a SoC subsystem and the name is a preprocessor define for a device ID.
Same with destination name. But as long as I can look for the stuff in the code, and am able to find it somehow, I can figure it out.

But with source/destination interface I found it nowhere in the code. I guess what is ment are those things in drivers/sciclient/sciclient_rm_priv.h in struct Sciclient_rmIrqIf,
those rbase and lbase things. And here you say that I shouldn't have to dive so deeply into the code. But where am I to find out what those interfaces are then instead?
Is there any documentation about them anywhere?

I am also not confident that people from our company who have not read up about the TI SDK and shouldn't have to, who just want to send and interrupt from some source they have to some interrupt controller would know that they need to do this over an interface called "pr1_iep0_cmp_intr_req" or similar (please don't try to find out what exactly this one means, it is just an example for something that is not explained well). I have no clue what that means,
how should they? And here I don't see where those things are explained (also when I say that such unexplained columns I find in many tables, for instance in the TRM where it says for instance in the interrupt mappings something about "source interrupts", where I have no idea what a "source interrupt" is ment to be. I only know what an interrupt source is. But that is another matter. Until know I ignored it and just assumed, it would mean "interrupt source").

Concerning the resource ranges, in the GPIO-mux-table I thought that the right output range can be found simply by providing the secondary host ID, as in your example



the type was the device ID of the interrupt router and the subtype would only say that the type is for an interrupt router.
So the range could only be fruther restricted inside the interrupt routers output table by the secondary host.
Which would, as I understand, tell the TISCI-API which is the target interrupt controller,
but for instance for MAIN_GPIOMUX_INTROUTER0, let's say I want only those for AM64X_DEV_PRU_ICSSG0 pr1_iep0_cap_intr_req I don't see how a secondary host ID would help me here. As far as I see it, I could only get the whole range for
AM64X_DEV_PRU_ICSSG0 over all destination interfaces, in this case pr1_iep0_cap_intr_req and  pr1_iep1_cap_intr_req
I am still looking for a way, let's say for instance only to get the resource range for AM64X_DEV_PRU_ICSSG0 pr1_iep0_cap_intr_req.
And as I see no connection between secondary host ID and the combination of destination name and destination interface.

It is commendable that you say the user of te SDK should not have to look into the code, but apparently I have to, since either functions that I'd like to use are not exposed or the functionality that I desire simply doesn't exist.
************************************************************************************

What I would expect from an interrupt abstraction (the one that I currently work on) would be:

I have some interrupt source that needs to be routed to a destination. Now I tell the API what my destination is and which is my source. In my imagination I would tell what the source is by providing source SoC device ID and source index. And then I would just tell the interrupt API what would be the destination MCU or destination interruot controller by providing a host ID.

And the API would do things like finding the right input and output lines and setting up the route.
And that is exactly what I want to provide to the user of my abstraction.


Best regards

Philip.

Hello Frank,
thank you for providing the results of your experiments. I will look into those tomorrow morning.
Wish you a good night (probably it is already morning in America, not sure).


Best regards

Philip.

Hi Philip,

Philip Schröder said:

And I need them to choose the right ones on their own. And it is quite hard to explain it to them when the documentation includes conflicting information.

I understand and agree with you.

Philip Schröder said:

I could provide a host ID, but it is not clear what that would achieve.
my understanding is for GPIOs that I would get only the output index numbers for AM64X_DEV_R5FSS0_CORE0 or only those for AM64X_DEV_R5FSS0_CORE1 for instance.

This is the intent:

• Sciclient_rmGetResourceRange() gets the Interrupt Router Outputs assigned to a particular Host.
• These assignments are made in the Board Configuration (see https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_12/exports/docs/api_guide_am243x/RESOURCE_ALLOCATION_GUIDE.html).
• The resource ranges are then translated by Sciclient_rmIrqTranslateIrOutput() into Interrupt Controller output numbers (the "Destination Index" in https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#main-gpiomux-introuter0-interrupt-router-output-destinations).
• Finally, the Interrupt Router route is set with Sciclient_rmIrqSet(), where the "Source Index" parameter is set according to https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#main-gpiomux-introuter0-interrupt-router-input-sources with the corrections I mention above.

Philip Schröder said:

In many tables I find columns with stuff that is nowhere explained (or I didn't find anything about it at least), like in the interrupt router example it says "source name"
 but without telling that it is the name of a SoC subsystem and the name is a preprocessor define for a device ID.
Same with destination name

I understand and agree with you.

Philip Schröder said:

But as long as I can look for the stuff in the code, and am able to find it somehow, I can figure it out.

Philip Schröder said:

And here you say that I shouldn't have to dive so deeply into the code. But where am I to find out what those interfaces are then instead?
Is there any documentation about them anywhere?

What I meant is that the documentation has gaps, and ideally you (or any user) shouldn't be required to understand all the details of the Sciclient code. I didn't mean to suggest you shouldn't dig into the code given the circumstances.

Philip Schröder said:

"pr1_iep0_cmp_intr_req" or similar

It must be related to the Compare Event Router, with ICSSG IEP0 as input events.

Philip Schröder said:

Concerning the resource ranges, in the GPIO-mux-table I thought that the right output range can be found simply by providing the secondary host ID

My understanding of the Secondary Host ID is it allows a Host to configure an interrupt route for another Host. Without using Secondary Host, an interrupt route can only be configured for the Host making the request. However, I need confirmation this from an Sciclient/TISCI/SYSFW expert.

Philip Schröder said:

I am still looking for a way, let's say for instance only to get the resource range for AM64X_DEV_PRU_ICSSG0 pr1_iep0_cap_intr_req.

Resource ranges (IR Output ranges) are assigned to Hosts, see https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/08_02_00_12/exports/docs/api_guide_am243x/RESOURCE_ALLOCATION_GUIDE.html.

As with the GPIOMUX Interrupt Router, you would:

• Use the Sciclient_rmGetResourceRange() API to get the Compare Event Router Output range assigned to a particular Host (e.g. R5F0_0).
• Translate any one of the values in the range to an Interrupt Controller input number ("Destination Index") using Sciclient_rmIrqTranslateIrOutput().
• Set the interrupt route through the Compare Event Router using Sciclient_rmIrqSet(). However, looking at https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#cmp-event-introuter0-interrupt-router-input-sources, it's not clear to me what the value of "Source Index" should be.

Philip Schröder said:

It is commendable that you say the user of te SDK should not have to look into the code, but apparently I have to, since either functions that I'd like to use are not exposed or the functionality that I desire simply doesn't exist.

I understand your viewpoint. I've raised all these points with the SDK team, and they have committed to updating the documentation. I'll ask about the expected timeline, and whether there is someone on the SDK team to provide you with better technical support.

If you think it might help, I can check the Sciclient/TISCI Compare Event Router behavior like I did for the GPIOMUX Interrupt Router. Please let me know if this would help.

Regards,
Frank

Hello Frank,
thank you for looking into it.
Ok, you said in the "Understanding intrrupts" topic that you think user's shouldn't have to look so deeply into the code and here as well and explained in in both topics. Ok, was not 100% sure, but as I get to know you in what you mean, I will not ask again when you say something like that, thank you.

Concerning the Secondary Host ID you said

Frank Livingston said:

My understanding of the Secondary Host ID is it allows a Host to configure an interrupt route for another Host. Without using Secondary Host, an interrupt route can only be configured for the Host making the request. However, I need confirmation this from an Sciclient/TISCI/SYSFW expert

I think you are absolutely right here, when we are talking about setting a route in the interrupt router.
But I was talking about the get resource range function. When I compare the values in tisci_devices.h with the first table here

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#interrupt-router-device-ids

it seems that the type for the resource range function at least concerning the interrupt routers is the INTR device ID.
The subtype then just says that it is an interrupt router.

So in this case without the Secondary Host ID setting in the request I would expect to get all outputs of an interrupt router.
So if I only want to get the ranges for a specific combination of destination name and destination interface like let's say for example for router CMP_EVEN_INTROUTER0 I want only the outputs for AM64X_DEV_GICSS0 together with spi



Then I somehow needed to choose a Host ID in a way that I restrict the results only to that range.
And my problem is that in the table I see the range defined by a combination of Destination Name and Destination Interface
while in the request te restricting elment seems to be the Host ID.
And right now, I am not sure how to translate Host ID to Device Name+Device Interface.
Or if that is even possible in the way that I imagine it.

Now in the above example one could simply think that the intr interface has a different Destination Name than the spi interface.
But I checked that this is not always the case.

For instance in the MAIN_GPIOMUX_INTROUTER0 output table we find



So we need the combination of both to clearly define the range.
That is my current remaining problem here, I would say. And the reason why I dig deep into the code.
Thank you for your help.


Best regards

Philip.

Hi Philip,

I'm reviewing your latest observations and will get back with you shortly.

Regards,
Frank

Hi Philip,

For the GPIO and Compare Event Routers, Sciclient_rmGetResourceRange() returns the range of IR Outputs assigned to the Host:

• type: interrupt router type (e.g. TISCI_DEV_MAIN_GPIOMUX_INTROUTER0, TISCI_DEV_CMP_EVENT_INTROUTER0)
• subtype: TISCI_RESASG_SUBTYPE_IR_OUTPUT
• secondary_host: Host for which range is being requested. If not used, Host from which Sciclient_rmGetResourceRange() is being called.

Resources ranges (here IR Outputs) are assigned in the file <SDK>/source\drivers\sciclient\sciclient_default_boardcfg\am64x_am243x\sciclient_defaultBoardcfg_rm.c.
        Please see details in https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/08_02_00_12/exports/docs/api_guide_am64x/RESOURCE_ALLOCATION_GUIDE.html.

Philip Schröder said:

So in this case without the Secondary Host ID setting in the request I would expect to get all outputs of an interrupt router.

I've shared an updated example code which shows Sciclient_rmGetResourceRange() being called to determine IR Outputs assigned to a particular host:

• Test #1: GPIO INTRTR Outputs assigned to this Host (where the function is being called)
• Test #2: GPIO INTRTR Outputs assigned to TISCI_HOST_ID_MAIN_0_R5_1 (same result as Test #1 since secondary Host is this Host)
• Test #3: GPIO INTRTR Outputs assigned to TISCI_HOST_ID_MAIN_1_R5_1
• Test #4: Compare INTRTR Outputs assigned to TISCI_HOST_ID_MAIN_1_R5_1
• Test #5: Compare INTRTR Outputs assigned to TISCI_HOST_ID_A53_2
• Test #6: Compare INTRTR Outputs assigned to TISCI_HOST_ID_A53_3 / TISCI_HOST_ID_ALL

Philip Schröder said:

And my problem is that in the table I see the range defined by a combination of Destination Name and Destination Interface

From what I can determine with the test results, the Sciclient_rmGetResourceRange() output range is in terms of the "IR Output Index" in the tables for the Output Destinations. These values are translated to "Destination Index" using Sciclient_rmIrqTranslateIrOutput().

Please let me know if this helps.

The SDK team has committed to updating the documentation. I believe this will be completed for the next SDK release.

Regards,
Frank

/cfs-file/__key/communityserver-discussions-components-files/908/0317.gpio_5F00_input_5F00_interrupt.c

Hello Frank,

Frank Livingston said:

Please let me know if this helps.

Sorry, thank you for that work, but I had all those information already before.
Maybe it is my fault for not phrasing my question clearly.

The question is, here in the tables for the output index

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#am64x-interrupt-management-device-descriptions

there are ranges of outputs grouped by the combination of IR Device ID + Destination Name + Destination Interface.
But when I do the Sciclient_rmGetResourceRange() call I get the output ranges as a combination of IR Device ID (type) + Host ID, (subtype is always interrupt router output).
Now how does "IR Device ID + Destination Name + Destination Interface" translate into IR Device ID + Host ID ?

For example:
Let's assume I want the range of all output index numbers for

Interrupt Router: AM64X_DEV_MAIN_GPIOMUX_INTROUTER0
Destination Name: AM64X_DEV_PRU_ICSSG0
Destination Interface: pr1_iep0_cap_intr_req

I would expect the range of the following output index number: {18, 19, 20, 21, 22, 23}

In the Sciclient_rmGetResourceRange() function I could provide the IR device ID of AM64X_DEV_MAIN_GPIOMUX_INTROUTER0, which is 3.
But since the only other variable parameter (subtype is not variable as it is always TISCI_RESASG_SUBTYPE_IR_OUTPUT for every interrupt router output) I can provide to further specify the range is Host ID, then how would I get the resource range for

Destination Name: AM64X_DEV_PRU_ICSSG0
Destination Interface: pr1_iep0_cap_intr_req

by specifying a secondary Host ID?


Thank you.


Best

Philip.

Hi Philip,

Thank you, I think I understand your concern now.

Device ID (type) selects the IR & Host ID (secondary_host) selects the Host.The Destination Name & Destination Interface are determined by the hardware connection between the IR Output and the Host Interrupt Controller.

If we use the following:

• IR Device ID (type) = TISCI_DEV_MAIN_GPIOMUX_INTROUTER0
• Host ID (secondary_host) = TISCI_HOST_ID_ICSSG_0

Now there is more than one IR Output range associated with TISCI_HOST_ID_ICSSG_0:

• Destination Name = TISCI_DEV_PRU_ICSSG0
• Destination Interface = pr1_iep0_cap_intr_req, Destination Index=0-5
  Destination Interface = pr1_iep1_cap_intr_req, Destination Index=0-5
  Destination Interface = pr1_slv_intr, Destination Index=46-53

However, so far we've only used tisci_msg_rm_get_resource_range_resp range_start and range_num for specifying the IR Output ranges assigned to a Host.

I see tisci_msg_rm_get_resource_range_resp also contains range_start_sec and range_num_sec. Perhaps this is intended to return a 2nd range.

Also, perhaps pr1_iep0_cap_intr_req & pr1_iep1_cap_intr_req would be combined into:

• range_start = 18
• range_num = 12

And for pr1_slv_intr:

• range_start_sec = 38
• range_num_sec = 8

Then Sciclient_rmIrqTranslateIrOutput() would translate the Sciclient_rmGetResourceRange() as follows:

• IR Output Index 18-23 → (TISCI_DEV_PRU_ICSSG0, pr1_iep0_cap_intr_req) Destination Index 0-5
• IR Output Index 24-29 → (TISCI_DEV_PRU_ICSSG0, pr1_iep1_cap_intr_req) Destination Index 0-5
• IR Output Index 38-45 → (TISCI_DEV_PRU_ICSSG0, pr1_slv_intr) Destination Index 46-53

This is speculation on my part, so (and sorry for saying this again!) I'll need to follow up with an Sciclient/TISCI/SYSFW expert.

A couple of notes:

• I don't see a Host ID for ICSSG_1 in source/drivers/sciclient/include/tisci/am64x_am243x/tisci_hosts.h. This might be a mistake since it should be possible to route GPIOMUX_INTRTR0 Outputs to ICSSG_1.
• I don't see any IR Outputs assigned to ICSSG_0/ICSSG_1 in sciclient_defaultBoardcfg_rm.c. So assigning IR Outputs to the ICSSG Interrupt Controllers would require updating the resource assignments.

Can you please confirm I'm on the right track?

Regards,
Frank

Hello Frank,
thank you for getting back to me.

Frank Livingston said:

I see tisci_msg_rm_get_resource_range_resp also contains range_start_sec and range_num_sec. Perhaps this is intended to return a 2nd range.

In my code I use this already.
As I understood it according to drivers/sciclient/include/tisci/rm/tisci_rm_core.h, line 98ff it says:

" * \brief Get resource range response message
 *
 * Response sent to host processor containing the requested resource range
 * assigned to the host who sent the range request."

So I would assume that range_start and range_num apply to the resource range of the host that sent the request.
But if I provide a secondary host, then I will get the secondary hosts resource range over range_start_sec and range_num_sec.
I rather don't believe that it means that I can get 2 different resource ranges.
This would not make much sense to me as there are in most cases more than 2 resource ranges per interrupt router.
But this is also just a speculation on my part.


Best regards

Philip.

Philip,

Ok, at least it appears I understand your concern. I think your concern is valid.

Philip Schröder said:

according to drivers/sciclient/include/tisci/rm/tisci_rm_core.h

I also see the following brief, unhelpful comments in the header file:

* \param range_start_sec
* Start index of retrieved secondary resource range.  Zero if a second
* resource range does not exist or if the resource is not valid.
*
* \param range_num_sec
* Number of resources in secondary range.  Zero if a second resource range
* does not exist or if the resource is not valid.

Also, when we provide a secondary host to the Sciclient_rmGetResourceRange(), we get the range back in range_start and range_num.

Philip Schröder said:

So I would assume that range_start and range_num apply to the resource range of the host that sent the request.
But if I provide a secondary host, then I will get the secondary hosts resource range over range_start_sec and range_num_sec.
I rather don't believe that it means that I can get 2 different resource ranges.

You're probably correct. It seems you have more expertise in this than I do at this point. As I said, this was speculation on my part.

We need the help on an expert in this software, or we need to update the SDK contents to allow the ICSSG routes to be configured, and then execute Sciclient_rmGetResourceRange() to see what is returned.

I'm reaching out to internal experts to see if they can shed some light on this. I'll keep you posted.

Regards,
Frank

Hello Frank,
I really appreciate your help. Let's not talk about expertise.
It is not that I really no much more about all that than you.

Besides according to the comments you have in tisci_rm_core.h I would believe that your speculation was right.
In our code the complete comment block looks like this though:

/**
 * \brief Get resource range response message
 *
 * Response sent to host processor containing the requested resource range
 * assigned to the host who sent the range request.
 *
 * The range_start and range_num values are zero if the type and subtype in the
 * range request do not form a unique resource type for the SoC.  In this case,
 * the response will still contain an ACK.
 *
 * \param hdr
 * Standard TISCI header
 *
 * \param range_start
 * Start index of retrieved resource range.  Zero if the resource is not valid.
 *
 * \param range_num
 * Number of resources in the range.  Zero if the resource is not valid.
 *
 * \param range_start_sec
 * Start index of retrieved secondary resource range.  Zero if the resource
 * is not valid.
 *
 * \param range_num_sec
 * Number of resources in secondary range.  Zero if the resource is not valid.
 */
struct tisci_msg_rm_get_resource_range_resp {
    struct tisci_header    hdr;
    uint16_t            range_start;
    uint16_t            range_num;
    uint16_t            range_start_sec;
    uint16_t            range_num_sec;
} __attribute__((__packed__));

Frank Livingston said:

We need the help on an expert in this software, or we need to update the SDK contents to allow the ICSSG routes to be configured, and then execute Sciclient_rmGetResourceRange() to see what is returned.

What I actually wanted was the other way around.

My current understanding is that on a specific system the active resource ranges are configured in drivers/sciclient/sciclient_default_boardcfg/am64x_am243x/sciclient_defaultBoardCfg_rm.c.
Then those can be read back by using Sciclient_rmGetResourceRange().

Now in my imagination I have an interrupt source that needs to be routed to an interrupt destination.
As I am coding in C++, I created an InterruptRouter class. which depends on several template parameters.
I want a Singleton InterruptRouter object that only exists once in the system.
But I don't want it to include all interrupt routers and all the inputs and outputs of all the available interrupt routers.
I want one object for every combination of "IR Device ID", "Destination Name" and "Destination Interface".
That object should only manage the INTR outputs of one such combination.

Normally I would have an interrupt source which is to be connected to a destination interrupt controller.
In my understanding I need to find the right interrupt controller input line that is ment for this kind of interrupt source.
The interrupt lines of the destination interrupt controller used in the routing are hardwired to the output lines of the interrupt router, as I see it.
So to find the right interrupt input line of the destination interrupt controller, I need to choose one with the right "Destination Name" and "Destination Interface" in the resource table here

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am64x/interrupt_cfg.html#am64x-interrupt-management-device-descriptions

Now let's say that I want to connect a GPIO over the interrupt router MAIN_GPIOMUX_INTROUTER0.
Let's assume that the user wants to connect to R5F Core0, and directly connect the interrupt router to the destination.

So the following configuration for the interrupt router output range would be correct:

IR Dev ID: AM64X_DEV_MAIN_GPIOMUX_INTROUTER0,
Destination Name: AM64X_DEV_R5FSS0_CORE0,
Destination Interface: intr

Now there are INTR Outputs 0-15 for this configuration.
The user probably doesn't care which one is used. All they want is to connect to one of them.
Also they will most probably not know which one to use, as other users might want to connect their sources as well without
having to look into a global table which of the outputs are already chosen by others.

So the preferred solution for me would be, that inside my code I use something like the Sciclient_rmGetResourceRange() function to get the range of interrupt router outputs that are applicable for the source that the user wants to connect to the destination interrupt controller.

I would preinitialize my InterruptRouter class with that range according to its template parameters as stated above of "IR Device ID", "Destination Name" and "Destination Interface". As there is no exposed function to find out which INTR output is still free, I will probably have my own list, where I assume that on system start all routes are still free.
And then, later on, when a user asks to connect his interrupt source over the interrupt router with preset "Destination Interface" and "Destination Name"I would just connect the source over the next free interrupt output, which I get from the list initialized from the resource range. Afterwards I would tell him the destination IRQ number (which is the interrupt router output that was used translated using the Sciclient_rmIrqTranslateIrOutput function).
That is what I want.

The way you wrote it seemed like you want to first connect all the routes and then get the connected routes using the resourceRange function.
Or did I misunderstand you here?


Best regards

Philip.

Also, what I see when looking at the defined host IDs in drivers/sciclient/include/tisci/am64x_am243x/tisci_hosts.h

/** DMSC(Secure): Device Management and Security Control */
#define TISCI_HOST_ID_DMSC (0U)
/** MAIN_0_R5_0(Secure): Cortex R5_0 context 0 on Main island(BOOT) */
#define TISCI_HOST_ID_MAIN_0_R5_0 (35U)
/** MAIN_0_R5_1(Non Secure): Cortex R5_0 context 1 on Main island */
#define TISCI_HOST_ID_MAIN_0_R5_1 (36U)
/** MAIN_0_R5_2(Secure): Cortex R5_0 context 2 on Main island */
#define TISCI_HOST_ID_MAIN_0_R5_2 (37U)
/** MAIN_0_R5_3(Non Secure): Cortex R5_0 context 3 on Main island */
#define TISCI_HOST_ID_MAIN_0_R5_3 (38U)
/** A53_0(Secure): Cortex a53 context 0 on Main islana - ATF */
#define TISCI_HOST_ID_A53_0 (10U)
/** A53_1(Non Secure): Cortex A53 context 1 on Main island - EL2/Hyp */
#define TISCI_HOST_ID_A53_1 (11U)
/** A53_2(Non Secure): Cortex A53 context 2 on Main island - VM/OS1 */
#define TISCI_HOST_ID_A53_2 (12U)
/** A53_3(Non Secure): Cortex A53 context 3 on Main island - VM2/OS2 */
#define TISCI_HOST_ID_A53_3 (13U)
/** M4_0(Non Secure): M4 */
#define TISCI_HOST_ID_M4_0 (30U)
/** MAIN_1_R5_0(Secure): Cortex R5_1 context 0 on Main island */
#define TISCI_HOST_ID_MAIN_1_R5_0 (40U)
/** MAIN_1_R5_1(Non Secure): Cortex R5_1 context 1 on Main island */
#define TISCI_HOST_ID_MAIN_1_R5_1 (41U)
/** MAIN_1_R5_2(Secure): Cortex R5_1 context 2 on Main island */
#define TISCI_HOST_ID_MAIN_1_R5_2 (42U)
/** MAIN_1_R5_3(Non Secure): Cortex R5_1 context 3 on Main island */
#define TISCI_HOST_ID_MAIN_1_R5_3 (43U)
/** ICSSG_0(Non Secure): ICSSG context 0 on Main island */
#define TISCI_HOST_ID_ICSSG_0 (50U)

/* Current context is SECURE */
#define SCICLIENT_SECURE_CONTEXT            (0U)

/* Current context is NON-SECURE */
#define SCICLIENT_NON_SECURE_CONTEXT        (1U)

/* ========================================================================== */
/*                         Structure Declarations                             */
/* ========================================================================== */

/**
 *  \brief Map structure used by #Sciclient_init function.
 */
typedef struct
{
    uint32_t context;
    /**< context(sec/non-sec) **/

    uint32_t hostId;
    /**< CPU ID of the A53/A72/R5F/DSP */

    uint32_t reqLowPrioThreadId;
    /**< Thread ID of the low priority thread(write) allowed for the CPU */

    uint32_t respThreadId;
    /**< Thread ID of the response thread(read) available for the CPU */

    uint32_t respIntrNum;
    /**< Response Interrupt Number. */
} Sciclient_MapStruct_t;

Hi Philip,

Sorry for the long delayed response. I'll loop back to finalize this thread once we've resolved all the issues offline.

Regards,
Frank

Philip,

Do you still have questions about this? If so, can you please reiterate them here, or open a new thread if the topics are different from the original question about the GPIO MUX source address issue?

Thanks and regards,
Frank

I don't think so, as we talked personally, most of my questions were answered.
Yet I would think, that we should write a final conclusion here.
I will do that but probably not today, as I am not finished with my tests.

Often times when I search a forum, looking for information, I find that at some point people have gone off topic or the question simply has no answer, except for people agreeing to private messaging for further help.

Though that helps them, it doesn't help me when finding the post years later.
So I would like to take care that my posts come to a conclusion that answers the initial question.
Please have some patience with me in this matter like you always had.
Thank you.

Philip,

Sound very good, thanks much!

Regards,
Frank