On Thu, Dec 17, 2015 at 11:31:14AM +, Qais Yousef wrote:
> > > Maybe it would help to look at the new IPI reservation API?
> > >
> > > https://lkml.org/lkml/2015/12/8/249
> >
> > Hmm.. not as much as I might have hoped.
> >
> > From the API, it looks like you're reserving IPIs to signal bet
On Fri, Dec 11, 2015 at 10:47:57AM +, Qais Yousef wrote:
> On 12/11/2015 12:39 AM, David Gibson wrote:
> >On Thu, Dec 10, 2015 at 10:20:49AM +, Qais Yousef wrote:
> >>
> >>The IPIs have two properties that are different from a regular interrupts:
> >>
> >> 1. An IPI is not only received
On 12/11/2015 12:39 AM, David Gibson wrote:
On Thu, Dec 10, 2015 at 10:20:49AM +, Qais Yousef wrote:
The IPIs have two properties that are different from a regular interrupts:
1. An IPI is not only received, it could also be sent.
Any interrupt is sent by the device, received by an i
On Thu, Dec 10, 2015 at 10:20:49AM +, Qais Yousef wrote:
> On 12/09/2015 04:50 PM, Rob Herring wrote:
> >On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote:
> >
> >>What I have in mind is:
> >>
> >> coproc {
> >> ipi-parent = <&gic>;
> >>
> >> ipis = ;
> >>
On 12/09/2015 04:50 PM, Rob Herring wrote:
On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote:
What I have in mind is:
coproc {
ipi-parent = <&gic>;
ipis = ;
ipi-names = "in";
};
This will allocate an IPI to go to cpu @CPU_VALUE passing @
On Wed, Dec 09, 2015 at 10:50:35AM -0600, Rob Herring wrote:
> On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote:
> > Hi,
> >
> > On 10/22/2015 12:55 PM, Jason Cooper wrote:
> >>
> >> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
> >>>
> >>> Is there anything more I can do to get mo
On Wed, Dec 9, 2015 at 9:27 AM, Qais Yousef wrote:
> Hi,
>
> On 10/22/2015 12:55 PM, Jason Cooper wrote:
>>
>> On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
>>>
>>> Is there anything more I can do to get more attention about this? I
>>> think Marc's suggestion is more generic and fu
Hi,
On 10/22/2015 12:55 PM, Jason Cooper wrote:
On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
Is there anything more I can do to get more attention about this? I
think Marc's suggestion is more generic and future proof, if I send
RFC patches for that would this be better?
Please
On 10/22/2015 02:43 PM, Rob Herring wrote:
On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef wrote:
Hi,
This is an attempt to revive a discussion on the right list this time with
all the correct people hopefully on CC.
devicetree-spec would be more appropriate list for something like this.
Thank
On Wed, Oct 14, 2015 at 5:18 AM, Qais Yousef wrote:
> Hi,
>
> This is an attempt to revive a discussion on the right list this time with
> all the correct people hopefully on CC.
devicetree-spec would be more appropriate list for something like this.
> While trying to upstream a driver, Thomas a
On Thu, Oct 22, 2015 at 11:44:16AM +0100, Qais Yousef wrote:
> Is there anything more I can do to get more attention about this? I
> think Marc's suggestion is more generic and future proof, if I send
> RFC patches for that would this be better?
Please do.
thx,
Jason.
--
To unsubscribe from this
Is there anything more I can do to get more attention about this? I
think Marc's suggestion is more generic and future proof, if I send RFC
patches for that would this be better?
Thanks,
Qais
On 10/14/2015 11:18 AM, Qais Yousef wrote:
Hi,
This is an attempt to revive a discussion on the righ
Hi,
This is an attempt to revive a discussion on the right list this time
with all the correct people hopefully on CC.
While trying to upstream a driver, Thomas and Marc Zyngier pointed out
the need for a generic IPI support in the kernel to allow driver to
reserve and send ones. Hopefully m
13 matches
Mail list logo
