Add functions to get and clear pending events for Pm1EventRegisterBlock - #325
Add functions to get and clear pending events for Pm1EventRegisterBlock#325ChocolateLoverRaj wants to merge 1 commit into
Conversation
1f1539f to
413eeb4
Compare
|
I tested this on QEMU q35 and on a Lenovo Z560 laptop. In my OS I was able to receive interrupts when the power button is pressed. Read the events, which contained power button, cleared the events, and then when I pressed the power button again I got another interrupt. Both machines use I/O address space and event length of |
413eeb4 to
5d61ce8
Compare
5d61ce8 to
be38acd
Compare
| } | ||
|
|
||
| /// Ignores the GAS access size and does a 16-bit read. | ||
| pub fn read_u16(&self, byte_offset: u64) -> u16 { |
There was a problem hiding this comment.
I wonder if a cleaner way of doing this would be to have a method to derive a GenericAddress with a different access width from another one? (i.e. 'split' the GAS into the different registers?
There was a problem hiding this comment.
We could do that. Then we could make functions for getting the status register and getting the control register. Would the derived GAS use lifetimes or Arc?
There was a problem hiding this comment.
Just a random thought - splitting a MappedGas has the potential to create fun with PhysicalMapping::drop, because you'll need to ensure the PhysicalMapping gets dropped only once. So if you create two new MappedGas objects you could:
- Create two new PhysicalMapping objects, one for each child. This would be wasteful but safe (I think)
- Wrap the child
MappedGasHandlers inManuallyDropor similar - but then the splitMappedGasobjects have a different type to the originals.
I suppose what I'm trying to say is to be careful 😄
There was a problem hiding this comment.
Hm yes, very true Martin 😬
I wonder if the safest way would be to have a 'cast' effectively fn cast(self) -> MappedGas and some sort of way to duplicate a mapping, but that does seem inefficient? Maybe this isn't so bad after all?
| Pm1EventFlags::from_bits_retain(bits) | ||
| } | ||
|
|
||
| pub fn clear_events(&self, events: Pm1EventFlags) { |
There was a problem hiding this comment.
I haven't read the spec on this in quite a while (but remember wiring this up locally ages ago) - is it a useful API to clear all events, or would it be better to clear a specific event that you've handled (I assume by writing with an individual bit set)?
There was a problem hiding this comment.
The way I have it now where you specify which events to clear is better. If you clear all events, you might miss an event.
There was a problem hiding this comment.
Apologies, I somehow misread this as clearing all the events. Yes, this is good.
|
Lovely, thank you for working on this! I think I got this working on QEMU a while ago on my OS but likely with some changes that haven't yet made it upstream. Just a few questions from my end. |
3 participants
Closes #323