On 2011-09-03 13:37, Blue Swirl wrote:
> On Sat, Sep 3, 2011 at 11:17 AM, Jan Kiszka wrote:
>> On 2011-09-03 10:58, Blue Swirl wrote:
>>> On Thu, Sep 1, 2011 at 9:08 AM, Jan Kiszka wrote:
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the s
On Sat, Sep 3, 2011 at 11:17 AM, Jan Kiszka wrote:
> On 2011-09-03 10:58, Blue Swirl wrote:
>> On Thu, Sep 1, 2011 at 9:08 AM, Jan Kiszka wrote:
>>> The master PIC is connected to the LINTIN0 of the APICs. As the APIC
>>> currently does not track the state of that line, we have to ask the PIC
>>>
On 2011-09-03 10:58, Blue Swirl wrote:
> On Thu, Sep 1, 2011 at 9:08 AM, Jan Kiszka wrote:
>> The master PIC is connected to the LINTIN0 of the APICs. As the APIC
>> currently does not track the state of that line, we have to ask the PIC
>> to reinject its IRQ after the CPU picked up an event from
On Thu, Sep 1, 2011 at 9:08 AM, Jan Kiszka wrote:
> The master PIC is connected to the LINTIN0 of the APICs. As the APIC
> currently does not track the state of that line, we have to ask the PIC
> to reinject its IRQ after the CPU picked up an event from the APIC.
>
> This introduces pic_get_outpu
The master PIC is connected to the LINTIN0 of the APICs. As the APIC
currently does not track the state of that line, we have to ask the PIC
to reinject its IRQ after the CPU picked up an event from the APIC.
This introduces pic_get_output to read the master PIC IRQ line state
without changing it.
