Hi Marc,
On 11/5/2018 10:14 PM, Marc Zyngier wrote:
> On 05/11/18 16:20, Lokesh Vutla wrote:
>> Hi Marc,
>>
>> On Monday 05 November 2018 09:06 PM, Marc Zyngier wrote:
>>> On 05/11/18 08:08, Lokesh Vutla wrote:
Hi Marc,
On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
> H
On 05/11/18 16:20, Lokesh Vutla wrote:
> Hi Marc,
>
> On Monday 05 November 2018 09:06 PM, Marc Zyngier wrote:
>> On 05/11/18 08:08, Lokesh Vutla wrote:
>>> Hi Marc,
>>>
>>> On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
Hi Marc,
On Sunday 28 October 2018 07:01 PM, Marc Zyn
Hi Marc,
On Monday 05 November 2018 09:06 PM, Marc Zyngier wrote:
On 05/11/18 08:08, Lokesh Vutla wrote:
Hi Marc,
On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
Hi Marc,
On Sunday 28 October 2018 07:01 PM, Marc Zyngier wrote:
Hi Lokesh,
On Fri, 26 Oct 2018 21:19:41 +0100,
Lokesh V
On 05/11/18 08:08, Lokesh Vutla wrote:
> Hi Marc,
>
> On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
>> Hi Marc,
>>
>> On Sunday 28 October 2018 07:01 PM, Marc Zyngier wrote:
>>> Hi Lokesh,
>>>
>>> On Fri, 26 Oct 2018 21:19:41 +0100,
>>> Lokesh Vutla wrote:
Hi Marc,
[
Hi Marc,
On Monday 29 October 2018 06:34 PM, Lokesh Vutla wrote:
Hi Marc,
On Sunday 28 October 2018 07:01 PM, Marc Zyngier wrote:
Hi Lokesh,
On Fri, 26 Oct 2018 21:19:41 +0100,
Lokesh Vutla wrote:
Hi Marc,
[..snip..]
[...]
+/**
+ * ti_sci_inta_register_event() - Register a event to an
On 11/1/18 9:52 AM, Marc Zyngier wrote:
On 31/10/18 20:33, Grygorii Strashko wrote:
"
NAK. Either this fits in the standard model, or we adapt the standard
model to catter for your particular use case. But we don't define a new,
TI specific API.
"
And I stand by what I've written.
Sry
On 31/10/18 20:33, Grygorii Strashko wrote:
>
>
> On 10/31/18 1:21 PM, Marc Zyngier wrote:
>> Hi Grygorii,
>>
>> On 31/10/18 16:39, Grygorii Strashko wrote:
>>
>> [...]
>>
>>> I'd try to provide some additional information here.
>>> (Sry, I'll still use term "events")
>>>
>>> As Lokesh explained
Hi Marc,
On 11/1/18 11:00 AM, Marc Zyngier wrote:
> On Thu, 01 Nov 2018 07:55:12 +,
> Peter Ujfalusi wrote:
>>
>> Lokesh,
>>
>> On 10/29/18 3:04 PM, Lokesh Vutla wrote:
> With the above information, linux should send a message to
> system-controller using TISCI protocol. After policin
Hi Marc,
On 10/31/18 8:21 PM, Marc Zyngier wrote:
> Well, I'm convinced that we do not want a networking driver to be tied
> to an interrupt architecture, and that the two should be completely
> independent. But that's my own opinion. I can only see two solutions
> moving forward:
>
> 1) You make
On Thu, 01 Nov 2018 07:55:12 +,
Peter Ujfalusi wrote:
>
> Lokesh,
>
> On 10/29/18 3:04 PM, Lokesh Vutla wrote:
> >>> With the above information, linux should send a message to
> >>> system-controller using TISCI protocol. After policing the given
> >>> information, system-controller does the
Lokesh,
On 10/29/18 3:04 PM, Lokesh Vutla wrote:
>>> With the above information, linux should send a message to
>>> system-controller using TISCI protocol. After policing the given
>>> information, system-controller does the following:
>>> - Attaches the interrupt(INTA input) to the device resourc
On 10/31/18 1:21 PM, Marc Zyngier wrote:
Hi Grygorii,
On 31/10/18 16:39, Grygorii Strashko wrote:
[...]
I'd try to provide some additional information here.
(Sry, I'll still use term "events")
As Lokesh explained in other mail on K3 SoC everything is generic and most
of resources allocate
On 10/31/2018 11:42 AM, Marc Zyngier wrote:
On 31/10/18 18:38, Santosh Shilimkar wrote:
On 10/31/2018 11:21 AM, Marc Zyngier wrote:
Hi Grygorii,
[...]
Well, I'm convinced that we do not want a networking driver to be tied
to an interrupt architecture, and that the two should be completely
On 31/10/18 18:38, Santosh Shilimkar wrote:
> On 10/31/2018 11:21 AM, Marc Zyngier wrote:
>> Hi Grygorii,
>>
>
> [...]
>
>>
>> Well, I'm convinced that we do not want a networking driver to be tied
>> to an interrupt architecture, and that the two should be completely
>> independent. But that's m
On 10/31/2018 11:21 AM, Marc Zyngier wrote:
Hi Grygorii,
[...]
Well, I'm convinced that we do not want a networking driver to be tied
to an interrupt architecture, and that the two should be completely
independent. But that's my own opinion. I can only see two solutions
moving forward:
1)
Hi Grygorii,
On 31/10/18 16:39, Grygorii Strashko wrote:
[...]
> I'd try to provide some additional information here.
> (Sry, I'll still use term "events")
>
> As Lokesh explained in other mail on K3 SoC everything is generic and most
> of resources allocated dynamicaly:
> - generic DMA channel
Hi Marc,
On 10/23/18 8:50 AM, Marc Zyngier wrote:
On Mon, 22 Oct 2018 15:35:41 +0100,
Lokesh Vutla wrote:
On Friday 19 October 2018 08:52 PM, Marc Zyngier wrote:
On 18/10/18 16:40, Lokesh Vutla wrote:
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt
Hi Marc,
On Sunday 28 October 2018 07:01 PM, Marc Zyngier wrote:
Hi Lokesh,
On Fri, 26 Oct 2018 21:19:41 +0100,
Lokesh Vutla wrote:
Hi Marc,
[..snip..]
[...]
+/**
+ * ti_sci_inta_register_event() - Register a event to an interrupt aggregator
+ * @dev: Device pointer to source gener
Hi Lokesh,
On Fri, 26 Oct 2018 21:19:41 +0100,
Lokesh Vutla wrote:
>
> Hi Marc,
>
> [..snip..]
> >> [...]
> >>
> > +/**
> > + * ti_sci_inta_register_event() - Register a event to an interrupt
> > aggregator
> > + * @dev: Device pointer to source generating the event
> >>
Hi Marc,
[..snip..]
[...]
+/**
+ * ti_sci_inta_register_event() - Register a event to an interrupt aggregator
+ * @dev: Device pointer to source generating the event
+ * @src_id:TISCI device ID of the event source
+ * @src_index: Event source index within the device.
+ * @virq:
Hi Marc,
On Tuesday 23 October 2018 07:20 PM, Marc Zyngier wrote:
Hi Lokesh,
On Mon, 22 Oct 2018 15:35:41 +0100,
Lokesh Vutla wrote:
Hi Marc,
On Friday 19 October 2018 08:52 PM, Marc Zyngier wrote:
Hi Lokesh,
On 18/10/18 16:40, Lokesh Vutla wrote:
Texas Instruments' K3 generation SoCs ha
Hi Lokesh,
On Mon, 22 Oct 2018 15:35:41 +0100,
Lokesh Vutla wrote:
>
> Hi Marc,
>
> On Friday 19 October 2018 08:52 PM, Marc Zyngier wrote:
> > Hi Lokesh,
> >
> > On 18/10/18 16:40, Lokesh Vutla wrote:
> >> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
> >> which is an i
Hi Marc,
On Friday 19 October 2018 08:52 PM, Marc Zyngier wrote:
Hi Lokesh,
On 18/10/18 16:40, Lokesh Vutla wrote:
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understo
On 2018-10-22 13:42, Peter Ujfalusi wrote:
> Lokesh,
>
> On 2018-10-18 18:40, Lokesh Vutla wrote:
>> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
>> which is an interrupt controller that does the following:
>> - Converts events to interrupts that can be understood by
>>
Lokesh,
On 2018-10-18 18:40, Lokesh Vutla wrote:
> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
> which is an interrupt controller that does the following:
> - Converts events to interrupts that can be understood by
> an interrupt router.
> - Allows for multiplexing of ev
Hi Lokesh,
On 18/10/18 16:40, Lokesh Vutla wrote:
> Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
> which is an interrupt controller that does the following:
> - Converts events to interrupts that can be understood by
> an interrupt router.
> - Allows for multiplexing of e
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
an interrupt router.
- Allows for multiplexing of events to interrupts.
- Allows for grouping of multiple events
27 matches
Mail list logo
