Hi Tony,
On 18/02/19 8:02 PM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla@xxxxxx> [190216 03:30]:
>> On 2/15/2019 9:46 PM, Tony Lindgren wrote:
>>> The dts node for the interrupt controller should describe a
>>> proper Linux device, that is with reg entries and so on.
>>
>> You are asking to just keep the compatible property :)
>
> Right, and then I realized this node is missing the standard
> reg entry too. And you're saying the registers are not even
> accissible from Linux.
>
> So based on that IMO you should not even have a device tree
> node for it at all. You should just have the interrupt
Practically lets look at what all I am adding in the DT node. Below is one such
example:
main_intr: interrupt-controller0 {
compatible = "ti,sci-intr";
interrupt-controller;
interrupt-parent = <&gic500>;
#interrupt-cells = <4>;
ti,sci = <&dmsc>;
ti,sci-dst-id = <56>;
ti,sci-rm-range-girq = <0x1>;
};
The following 4 properties are required at least for probing, to represent the
hierarchy and for interrupt definition:
compatible = "ti,sci-intr";
interrupt-controller;
interrupt-parent = <&gic500>;
#interrupt-cells = <4>;
The remaining 3 properties represents the TISCI interface. Let's go step by step:
* ti,sci = <&dmsc> :This is the phandle to the firmware protocol driver using
which the messages are sent
* ti,sci-dst-id = <56> : This is the TISCI device ID for the parent controller
for which your irqs needs to be connected. As I said this cannot be queried from
sysfw and this is the input to the messages that are send to sysfw.
* ti,sci-rm-range-girq = <0x1>: This define the ids using which the parent-irq
ranges that are allocated to this interrupt router instance can be queried from
sysfw.
If the above 2 properties are to be added as driver phandle then for every
instance of interrupt router in the SoC, a new compatible needs to be created. I
don't think this is a desirable solution.
With this can you tell me how can we not have a device-tree and still support
irq allocation?
Also, this is not the first time a driver based on a firmware is being added.
K2g clock, power and reset drivers are based on this where device ids are being
passed from consumers. Similarly arm scpi based drivers are also available.
Thanks and regards,
Lokesh
