Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1212126 > unrolled thread

[PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-24 14:40 +0200
    Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-24 14:50 +0200
      Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-24 15:10 +0200
        Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Marc Zyngier <marc.zyngier@arm.com> - 2015-08-24 15:40 +0200
          Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-24 16:30 +0200
            Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-24 17:10 +0200
              Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-24 18:40 +0200
                Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Marc Zyngier <marc.zyngier@arm.com> - 2015-08-24 19:20 +0200
                  Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-26 13:30 +0200
                    Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-26 15:30 +0200
                      Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-26 17:00 +0200
                        Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-26 17:10 +0200
                          Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-26 17:50 +0200
                            Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-26 23:50 +0200
                              Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Jiang Liu <jiang.liu@linux.intel.com> - 2015-08-27 04:30 +0200
                              Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-28 12:40 +0200
                                Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-28 16:30 +0200
                                  Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-28 17:20 +0200
                                  Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-09-02 11:40 +0200
                                    Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Marc Zyngier <marc.zyngier@arm.com> - 2015-09-02 12:00 +0200
                                      Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-09-02 12:50 +0200
                                        Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Marc Zyngier <marc.zyngier@arm.com> - 2015-09-02 14:00 +0200
                                          Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-09-02 15:30 +0200
                                            Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Marc Zyngier <marc.zyngier@arm.com> - 2015-09-02 16:20 +0200
                                      Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Jason Cooper <jason@lakedaemon.net> - 2015-09-02 14:20 +0200
        Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Thomas Gleixner <tglx@linutronix.de> - 2015-08-24 17:00 +0200
          Re: [PATCH 01/10] irqchip: irq-mips-gic: export gic_send_ipi Qais Yousef <qais.yousef@imgtec.com> - 2015-08-24 17:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1217508

On 09/02/2015 10:55 AM, Marc Zyngier wrote:
> On 02/09/15 10:33, Qais Yousef wrote:
>> On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
>>> On Fri, 28 Aug 2015, Qais Yousef wrote:
>>>> Thanks a lot for the detailed explanation. I wasn't looking for a quick and
>>>> dirty solution but my view of the problem is much simpler than yours so my
>>>> idea of a solution would look quick and dirty. I have a better appreciation of
>>>> the problem now and a way to approach it :-)
>>>>
>>>>   From DT point of view are we OK with this form then
>>>>
>>>>       coprocessor {
>>>>               interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>>>               interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>;
>>>>       }
>>>>
>>>> and if the root controller sends normal IPI as it sends normal device
>>>> interrupts then interrupt-sink can be a standard interrupts property (like in
>>>> my case)
>>>>
>>>>       coprocessor {
>>>>               interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>>>               interrupts = <INT_SPEC>;
>>>>       }
>>>>
>>>> Does this look right to you? Is there something else that needs to be covered
>>>> still?
>>> I'm not an DT wizard. I leave that to the DT experts.
>>>    
>> Hi Marc Zyngier, Mark Rutland,
>>
>> Any comments about the DT binding for the IPIs?
>>
>> To recap, the proposal which is based on Marc Zyngier's is to use
>> interrupt-source to represent an IPI from Linux CPU to a coprocessor and
>> interrupt-sink to receive an IPI from coprocessor to Linux CPU.
>> Hopefully the description above is self explanatory. Please let me know
>> if you need more info. Thomas covered the routing, synthesising, and
>> requesting parts in the core code. The remaining (high level) issue is
>> how to describe the IPIs in DT.
> I'm definitely *not* a DT expert! ;-) My initial binding proposal was
> only for wired interrupts, not for IPIs. There is definitely some common
> aspects, except for one part:
>
> Who decides on the IPI number? So far, we've avoided encoding IPI
> numbers in the DT just like we don't encode MSIs, because they are
> programmable things. My feeling is that we shouldn't put the IPI number
> in the DT because the rest of the kernel uses them as well and could
> decide to use this particular IPI number for its own use: *clash*.

I think this is covered in Thomas proposal to reserve IPIs. His thoughts 
is to use a separate irq-domain for IPIs and use irq_reserve_ipi() and 
irq_destroy_ipi() to get and release IPIs.

>
> The way I see it would be to have a pool of IPI numbers that the kernel
> requests for its own use first, leaving whatever remains to drivers.

That's what Thomas thinks too and he covered this by using 
irq_reserve_ipi() and irq_destroy_ipi().

     https://lkml.org/lkml/2015/8/26/713

It's worth noting in the light of this that INT_SPEC should be optional 
since for hardware similar to mine there's not much to tell the 
controller if it's all dynamic except where we want the IPI to be routed 
to - the INT_SPEC is implicitly defined by the notion it's an IPI.

Thanks,
Qais

>
> Mark (as *you* are the expert ;-), what do you think?
>
> 	M.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1217547

On 02/09/15 11:48, Qais Yousef wrote:
> On 09/02/2015 10:55 AM, Marc Zyngier wrote:
>> On 02/09/15 10:33, Qais Yousef wrote:
>>> On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
>>>> On Fri, 28 Aug 2015, Qais Yousef wrote:
>>>>> Thanks a lot for the detailed explanation. I wasn't looking for a quick and
>>>>> dirty solution but my view of the problem is much simpler than yours so my
>>>>> idea of a solution would look quick and dirty. I have a better appreciation of
>>>>> the problem now and a way to approach it :-)
>>>>>
>>>>>   From DT point of view are we OK with this form then
>>>>>
>>>>>       coprocessor {
>>>>>               interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>>>>               interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>;
>>>>>       }
>>>>>
>>>>> and if the root controller sends normal IPI as it sends normal device
>>>>> interrupts then interrupt-sink can be a standard interrupts property (like in
>>>>> my case)
>>>>>
>>>>>       coprocessor {
>>>>>               interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
>>>>>               interrupts = <INT_SPEC>;
>>>>>       }
>>>>>
>>>>> Does this look right to you? Is there something else that needs to be covered
>>>>> still?
>>>> I'm not an DT wizard. I leave that to the DT experts.
>>>>    
>>> Hi Marc Zyngier, Mark Rutland,
>>>
>>> Any comments about the DT binding for the IPIs?
>>>
>>> To recap, the proposal which is based on Marc Zyngier's is to use
>>> interrupt-source to represent an IPI from Linux CPU to a coprocessor and
>>> interrupt-sink to receive an IPI from coprocessor to Linux CPU.
>>> Hopefully the description above is self explanatory. Please let me know
>>> if you need more info. Thomas covered the routing, synthesising, and
>>> requesting parts in the core code. The remaining (high level) issue is
>>> how to describe the IPIs in DT.
>> I'm definitely *not* a DT expert! ;-) My initial binding proposal was
>> only for wired interrupts, not for IPIs. There is definitely some common
>> aspects, except for one part:
>>
>> Who decides on the IPI number? So far, we've avoided encoding IPI
>> numbers in the DT just like we don't encode MSIs, because they are
>> programmable things. My feeling is that we shouldn't put the IPI number
>> in the DT because the rest of the kernel uses them as well and could
>> decide to use this particular IPI number for its own use: *clash*.
> 
> I think this is covered in Thomas proposal to reserve IPIs. His thoughts 
> is to use a separate irq-domain for IPIs and use irq_reserve_ipi() and 
> irq_destroy_ipi() to get and release IPIs.
> 
>>
>> The way I see it would be to have a pool of IPI numbers that the kernel
>> requests for its own use first, leaving whatever remains to drivers.
> 
> That's what Thomas thinks too and he covered this by using 
> irq_reserve_ipi() and irq_destroy_ipi().
> 
>      https://lkml.org/lkml/2015/8/26/713

Ah, I missed that, sorry for the noise. This looks very sensible.

> It's worth noting in the light of this that INT_SPEC should be optional 
> since for hardware similar to mine there's not much to tell the 
> controller if it's all dynamic except where we want the IPI to be routed 
> to - the INT_SPEC is implicitly defined by the notion it's an IPI.

Well, I'd think that the INT_SPEC should say that it is an IPI, and I
don't believe we should omit it. On the ARM GIC side, our interrupts are
typed (type 0 is a normal wired interrupt, type 1 a per-cpu interrupt,
and we could allocate type 2 to identify an IPI).

But we do need to identify it properly, as we should be able to cover
both IPIs and normal wired interrupts.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1217600

On 09/02/2015 12:53 PM, Marc Zyngier wrote:
> On 02/09/15 11:48, Qais Yousef wrote:
>> It's worth noting in the light of this that INT_SPEC should be optional
>> since for hardware similar to mine there's not much to tell the
>> controller if it's all dynamic except where we want the IPI to be routed
>> to - the INT_SPEC is implicitly defined by the notion it's an IPI.
> Well, I'd think that the INT_SPEC should say that it is an IPI, and I
> don't believe we should omit it. On the ARM GIC side, our interrupts are
> typed (type 0 is a normal wired interrupt, type 1 a per-cpu interrupt,
> and we could allocate type 2 to identify an IPI).

I didn't mean to omit it completely, but just being optional so it's 
specified if the intc needs this info only. I'm assuming that INT_SPEC 
is interrupt controller specific. If not, then ignore me :-)

>
> But we do need to identify it properly, as we should be able to cover
> both IPIs and normal wired interrupts.

I'm a bit confused here. What do you mean by normal wired interrupts? I 
thought this DT binding is only to describe IPIs that needs reserving 
and routing. What am I missing?

Thanks,
Qais
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1217625

On 02/09/15 14:25, Qais Yousef wrote:
> On 09/02/2015 12:53 PM, Marc Zyngier wrote:
>> On 02/09/15 11:48, Qais Yousef wrote:
>>> It's worth noting in the light of this that INT_SPEC should be optional
>>> since for hardware similar to mine there's not much to tell the
>>> controller if it's all dynamic except where we want the IPI to be routed
>>> to - the INT_SPEC is implicitly defined by the notion it's an IPI.
>> Well, I'd think that the INT_SPEC should say that it is an IPI, and I
>> don't believe we should omit it. On the ARM GIC side, our interrupts are
>> typed (type 0 is a normal wired interrupt, type 1 a per-cpu interrupt,
>> and we could allocate type 2 to identify an IPI).
> 
> I didn't mean to omit it completely, but just being optional so it's 
> specified if the intc needs this info only. I'm assuming that INT_SPEC 
> is interrupt controller specific. If not, then ignore me :-)

It is, but I don't think it can really be made optional.

>>
>> But we do need to identify it properly, as we should be able to cover
>> both IPIs and normal wired interrupts.
> 
> I'm a bit confused here. What do you mean by normal wired interrupts? I 
> thought this DT binding is only to describe IPIs that needs reserving 
> and routing. What am I missing?

Look at my initial proposal, and the way I was describing a device
having an interrupt source, and two possible interrupt sinks, one being
a CPU and the other being another device.

I'm looking at solving that case as well, possibly with the same
infrastructure (the routing bit should be the same).

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1217556

On Wed, Sep 02, 2015 at 10:55:20AM +0100, Marc Zyngier wrote:
> On 02/09/15 10:33, Qais Yousef wrote:
> > On 08/28/2015 03:22 PM, Thomas Gleixner wrote:
> >> On Fri, 28 Aug 2015, Qais Yousef wrote:
> >>> Thanks a lot for the detailed explanation. I wasn't looking for a quick and
> >>> dirty solution but my view of the problem is much simpler than yours so my
> >>> idea of a solution would look quick and dirty. I have a better appreciation of
> >>> the problem now and a way to approach it :-)
> >>>
> >>>  From DT point of view are we OK with this form then
> >>>
> >>>      coprocessor {
> >>>              interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
> >>>              interrupt-sink = <&intc INT_SPEC CPU_HWAFFINITY>;
> >>>      }
> >>>
> >>> and if the root controller sends normal IPI as it sends normal device
> >>> interrupts then interrupt-sink can be a standard interrupts property (like in
> >>> my case)
> >>>
> >>>      coprocessor {
> >>>              interrupt-source = <&intc INT_SPEC COP_HWAFFINITY>;
> >>>              interrupts = <INT_SPEC>;
> >>>      }
> >>>
> >>> Does this look right to you? Is there something else that needs to be covered
> >>> still?
> >> I'm not an DT wizard. I leave that to the DT experts.
> >>   
> > 
> > Hi Marc Zyngier, Mark Rutland,
> > 
> > Any comments about the DT binding for the IPIs?
> > 
> > To recap, the proposal which is based on Marc Zyngier's is to use 
> > interrupt-source to represent an IPI from Linux CPU to a coprocessor and 
> > interrupt-sink to receive an IPI from coprocessor to Linux CPU. 
> > Hopefully the description above is self explanatory. Please let me know 
> > if you need more info. Thomas covered the routing, synthesising, and 
> > requesting parts in the core code. The remaining (high level) issue is 
> > how to describe the IPIs in DT.
> 
> I'm definitely *not* a DT expert! ;-) My initial binding proposal was
> only for wired interrupts, not for IPIs. There is definitely some common
> aspects, except for one part:
> 
> Who decides on the IPI number? So far, we've avoided encoding IPI
> numbers in the DT just like we don't encode MSIs, because they are
> programmable things. My feeling is that we shouldn't put the IPI number
> in the DT because the rest of the kernel uses them as well and could
> decide to use this particular IPI number for its own use: *clash*.

Agree.  The best way I've found to design DT bindings is to imagine
providing the DT to something other than Linux.  The DT should *only* be
describing the hardware.  As such, I think we should be describing the
connection here, and leaving the assignment up to the OS.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212279

On Mon, 24 Aug 2015, Qais Yousef wrote:
> On 08/24/2015 01:49 PM, Thomas Gleixner wrote:
> > On Mon, 24 Aug 2015, Qais Yousef wrote:
> > 
> > > Some drivers might require to send ipi to other cores. So export it.
> > Which IPIs do you need to send from a driver which are not exposed by
> > the SMP functions already?
> 
> It's not an SMP IPI. We use GIC to exchange interrupts between AXD and the
> host system since AXD is another MIPS core in the cluster.

So that should have been in the changelog to begin with.
 
> > > This will be used later by AXD driver.
> > That smells fishy and it wants a proper explanation WHY and not just a
> > sloppy statement that it will be used later. I can figure that out
> > myself as exporting a function without using it does not make any sense.
> 
> Sorry for the terse explanation. As pointed above AXD uses GIC to send and
> receive interrupts to the host core. Without this change I can't compile the
> driver as a driver module because the symbol is not exported.

Really? Exporting it solves that problem then. That's interesting news
for me.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1212306

On 08/24/2015 03:55 PM, Thomas Gleixner wrote:
> On Mon, 24 Aug 2015, Qais Yousef wrote:
>> On 08/24/2015 01:49 PM, Thomas Gleixner wrote:
>>> On Mon, 24 Aug 2015, Qais Yousef wrote:
>>>
>>>> Some drivers might require to send ipi to other cores. So export it.
>>> Which IPIs do you need to send from a driver which are not exposed by
>>> the SMP functions already?
>> It's not an SMP IPI. We use GIC to exchange interrupts between AXD and the
>> host system since AXD is another MIPS core in the cluster.
> So that should have been in the changelog to begin with.
>   

OK sorry for the confusion. I'll amend the changelog and be more careful 
in the future.

Thanks,
Qais

>>>> This will be used later by AXD driver.
>>> That smells fishy and it wants a proper explanation WHY and not just a
>>> sloppy statement that it will be used later. I can figure that out
>>> myself as exporting a function without using it does not make any sense.
>> Sorry for the terse explanation. As pointed above AXD uses GIC to send and
>> receive interrupts to the host core. Without this change I can't compile the
>> driver as a driver module because the symbol is not exported.
> Really? Exporting it solves that problem then. That's interesting news
> for me.
>
> Thanks,
>
> 	tglx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web