On 13/02/18 15:01, Andre Przywara wrote:
Hi,
Hi Andre,
On 13/02/18 12:02, Julien Grall wrote:
On 12/02/18 17:53, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/02/18 13:55, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
When playing around with hardware mapped, l
Hi,
On 13/02/18 12:02, Julien Grall wrote:
> On 12/02/18 17:53, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 12/02/18 13:55, Julien Grall wrote:
>>> Hi Andre,
>>>
>>> On 09/02/18 14:39, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
On 12/02/18 17:53, Andre Przywara wrote:
Hi,
Hi Andre,
On 12/02/18 13:55, Julien Grall wrote:
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active state of an interrupt at
s
Hi,
On 12/02/18 13:55, Julien Grall wrote:
> Hi Andre,
>
> On 09/02/18 14:39, Andre Przywara wrote:
>> When playing around with hardware mapped, level triggered virtual IRQs,
>> there is the need to explicitly set the active state of an interrupt at
>> some point in time.
>> To prepare the GIC fo
Hi Andre,
On 09/02/18 14:39, Andre Przywara wrote:
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active state of an interrupt at
some point in time.
To prepare the GIC for that, we introduce a set_active_state() function
to let th
When playing around with hardware mapped, level triggered virtual IRQs,
there is the need to explicitly set the active state of an interrupt at
some point in time.
To prepare the GIC for that, we introduce a set_active_state() function
to let the VGIC manipulate the state of an associated hardware