On 29 January 2018 at 12:18, Wei Xu wrote:
> On 2018/1/26 18:01, Peter Maydell wrote:
>> No, that's not right either. int_level should already have the
>> RX bit set, because pl011_put_fifo() sets that bit when it gets a
>> character from QEMU and puts it into the FIFO.
>>
>> Does something else c
On Mon, Jan 29, 2018 at 11:37:05AM +, Wei Xu wrote:
> Hi Andrew,
>
> On 2018/1/29 10:29, Andrew Jones wrote:
> > On Fri, Jan 26, 2018 at 06:01:33PM +, Peter Maydell wrote:
> >> On 26 January 2018 at 17:33, Wei Xu wrote:
> >>> On 2018/1/26 17:15, Peter Maydell wrote:
> The pl011 code
Hi Peter,
On 2018/1/26 18:01, Peter Maydell wrote:
> On 26 January 2018 at 17:33, Wei Xu wrote:
>> On 2018/1/26 17:15, Peter Maydell wrote:
>>> The pl011 code should call qemu_set_irq(..., 1) when the
>>> guest enables interrupts on the device by writing to the int_enabled
>>> (UARTIMSC) register
Hi Andrew,
On 2018/1/29 10:29, Andrew Jones wrote:
> On Fri, Jan 26, 2018 at 06:01:33PM +, Peter Maydell wrote:
>> On 26 January 2018 at 17:33, Wei Xu wrote:
>>> On 2018/1/26 17:15, Peter Maydell wrote:
The pl011 code should call qemu_set_irq(..., 1) when the
guest enables interrupt
On 29 January 2018 at 10:29, Andrew Jones wrote:
> On Fri, Jan 26, 2018 at 06:01:33PM +, Peter Maydell wrote:
>> On 26 January 2018 at 17:33, Wei Xu wrote:
>> > On 2018/1/26 17:15, Peter Maydell wrote:
>> >> The pl011 code should call qemu_set_irq(..., 1) when the
>> >> guest enables interrup
On Fri, Jan 26, 2018 at 06:01:33PM +, Peter Maydell wrote:
> On 26 January 2018 at 17:33, Wei Xu wrote:
> > On 2018/1/26 17:15, Peter Maydell wrote:
> >> The pl011 code should call qemu_set_irq(..., 1) when the
> >> guest enables interrupts on the device by writing to the int_enabled
> >> (UAR
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 5a6b5091.8030...@hisilicon.com
Subject: [Qemu-devel] [Qemu-arm] [PATCH] pl011: do not put into fifo before
enabled the interruption
=== TEST SCRIPT BEGIN ===
#!/bin/bash
If the user pressed some keys in the console during the guest booting,
the console will be hanged after entering the shell.
Because in the above case the pl011_can_receive will return 0 that
the pl011_receive will not be called. That means no interruption will
be injected in to the kernel and the p
Hi Peter,
On 2018/1/26 17:15, Peter Maydell wrote:
> On 26 January 2018 at 17:05, Wei Xu wrote:
>> On 2018/1/26 16:36, Peter Maydell wrote:
>>> If the user presses keys before interrupts are enabled,
>>> what ought to happen is:
>>> * we put the key in the FIFO, and update the int_level flags
>>
Hi Peter,
On 2018/1/26 16:36, Peter Maydell wrote:
> On 26 January 2018 at 16:00, Wei Xu wrote:
>> If the user pressed some keys in the console during the guest booting,
>> the console will be hanged after entering the shell.
>> Because in the above case the pl011_can_receive will return 0 that
>
On 26 January 2018 at 17:33, Wei Xu wrote:
> On 2018/1/26 17:15, Peter Maydell wrote:
>> The pl011 code should call qemu_set_irq(..., 1) when the
>> guest enables interrupts on the device by writing to the int_enabled
>> (UARTIMSC) register. That will be a 0-to-1 level change and the KVM
>> VGIC s
On 26 January 2018 at 17:05, Wei Xu wrote:
> On 2018/1/26 16:36, Peter Maydell wrote:
>> If the user presses keys before interrupts are enabled,
>> what ought to happen is:
>> * we put the key in the FIFO, and update the int_level flags
>> * when the FIFO is full, can_receive starts returning 0
On 26 January 2018 at 16:00, Wei Xu wrote:
> If the user pressed some keys in the console during the guest booting,
> the console will be hanged after entering the shell.
> Because in the above case the pl011_can_receive will return 0 that
> the pl011_receive will not be called. That means no inte
13 matches
Mail list logo