summary refs log tree commit diff stats
path: root/results/scraper/launchpad/1478376
blob: 00711f59679a979adafc43598142efa4bc00ddd5 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
PL050 KMIDATA register does not reset

static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){
  ...
   case 2: /* KMIDATA */
        if (s->pending)
            s->last = ps2_read_data(s->dev);
        return s->last;
}

When the receive queue is empty (s->pending is false), is the KMIDATA register supposed to be reset to 0x00? In the current implementation,  the  KMIDATA  does not reverse its value after interrupt is lowered.

On 26 July 2015 at 19:16, T-T Yu <email address hidden> wrote:
> Public bug reported:
>
> static uint32_t pl050_read(void *opaque, target_phys_addr_t offset){
>   ...
>    case 2: /* KMIDATA */
>         if (s->pending)
>             s->last = ps2_read_data(s->dev);
>         return s->last;
> }
>
> When the receive queue is empty (s->pending is false), is the KMIDATA
> register supposed to be reset to 0x00? In the current implementation,
> the  KMIDATA  does not reverse its value after interrupt is lowered.

The documentation for the PL050:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0143c/i1014040.html

just says that when KMIDATA is read you get the value in the
receive data register. The implication is that if you read
it multiple times you'll just continue to read the same
value it holds until the keyboard sends further data to be
clocked into the register.

Are you saying that real hardware behaves differently?

thanks
-- PMM


Yes. In our pl050 keyboard controller, the KMIDATA is reset once the receive queue is empty. 

Looking through old bug tickets... is this still an issue with the latest version of QEMU? Or could we close this ticket nowadays?


[Expired for QEMU because there has been no activity for 60 days.]