Hi Chris,
On 07/07/17 19:08, Chris Patterson wrote:
On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall wrote:
Hi Chris,
On 06/07/17 23:00, Chris Patterson wrote:
The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route. Presu
Hi Chris,
Sorry for the late reply.
On 24/07/17 20:38, Chris Patterson wrote:
On Fri, Jul 7, 2017 at 2:53 PM, Chris Patterson wrote:
On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote:
Hi Chris,
On 07/07/17 00:12, Chris Patterson wrote:
So why do you want the hardware domain to interac
On Fri, Jul 7, 2017 at 2:53 PM, Chris Patterson wrote:
> On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote:
>> Hi Chris,
>>
>> On 07/07/17 00:12, Chris Patterson wrote:
So why do you want the hardware domain to interact with the ictlr? Could
not
you hide it completely?
On Fri, Jul 7, 2017 at 12:30 PM, Julien Grall wrote:
> Hi Chris,
>
> On 07/07/17 00:12, Chris Patterson wrote:
>>>
>>>
>>> So why do you want the hardware domain to interact with the ictlr? Could
>>> not
>>> you hide it completely?
>>>
>>
>> snip
>>
>>> What would happen if you enable the interrup
On Fri, Jul 7, 2017 at 12:25 PM, Julien Grall wrote:
> Hi Chris,
>
>
> On 06/07/17 23:00, Chris Patterson wrote:
The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route. Presumably,
there may be custom board
Hi Chris,
On 07/07/17 00:12, Chris Patterson wrote:
So why do you want the hardware domain to interact with the ictlr? Could not
you hide it completely?
snip
What would happen if you enable the interrupt here for the guest? Should not
you do it when the guest is requesting to enable (see v
Hi Chris,
On 06/07/17 23:00, Chris Patterson wrote:
The purpose of tegra_interrupt_compat is to maintain a tegra-specific
whitelist of interrupt controllers we know how to route. Presumably,
there may be custom boards out there that may have additional
interrupt routing capabilities that this p
>
> So why do you want the hardware domain to interact with the ictlr? Could not
> you hide it completely?
>
snip
> What would happen if you enable the interrupt here for the guest? Should not
> you do it when the guest is requesting to enable (see vgic_enable_irqs).
>
>
> Also, how about EOI an
>> The purpose of tegra_interrupt_compat is to maintain a tegra-specific
>> whitelist of interrupt controllers we know how to route. Presumably,
>> there may be custom boards out there that may have additional
>> interrupt routing capabilities that this patch set would not support
>> as-is. I'm n
Hello,
On 06/04/2017 20:47, Chris Patterson wrote:
From: "Chris Patterson"
Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected
Hello Chris,
On 17/04/2017 16:03, Chris Patterson wrote:
+static const char * const tegra_dt_compat[] __initconst =
+{
+"nvidia,tegra120", /* Tegra K1 */
This is still tegra120 (not tegra124), is that intended? If so, it is
still missing from arch/arm*/boot/dts. Do you have a pointer?
I
>> +static const char * const tegra_dt_compat[] __initconst =
>> +{
>> +"nvidia,tegra120", /* Tegra K1 */
>
> This is still tegra120 (not tegra124), is that intended? If so, it is
> still missing from arch/arm*/boot/dts. Do you have a pointer?
It was not intended; thank you for catching it. I
On Thu, 6 Apr 2017, Chris Patterson wrote:
> From: "Chris Patterson"
>
> Tegra devices have a legacy interrupt controller (lic, or ictlr) that
> must be programmed in parallel with their primary GIC. For all intents
> and purposes, we treat these devices attached to this controller as
> connected
From: "Chris Patterson"
Tegra devices have a legacy interrupt controller (lic, or ictlr) that
must be programmed in parallel with their primary GIC. For all intents
and purposes, we treat these devices attached to this controller as
connected to the primary GIC, as it will be handling their inter
14 matches
Mail list logo