@@ -181,7 +181,6 @@ typedef struct IRQ_queue_t {
uint32_t queue[BF_WIDTH(MAX_IRQ)];
int next;
int priority;
- int pending; /* nr of pending bits in queue */
} IRQ_queue_t;
typedef struct IRQ_src_t {
@@ -270,13 +269,11 @@ typedef struct OpenPICState {
static inline void IRQ_setbit(IRQ_queue_t *q, int n_IRQ)
{
- q->pending++;
set_bit(q->queue, n_IRQ);
}
static inline void IRQ_resetbit(IRQ_queue_t *q, int n_IRQ)
{
- q->pending--;
reset_bit(q->queue, n_IRQ);
}
@@ -292,12 +289,6 @@ static void IRQ_check(OpenPICState *opp, IRQ_queue_t *q)
next = -1;
priority = -1;
-
- if (!q->pending) {
- /* IRQ bitmap is empty */
- goto out;
- }
-
for (i = 0; i < opp->max_irq; i++) {
if (IRQ_testbit(q, i)) {
DPRINTF("IRQ_check: irq %d set ivpr_pr=%d pr=%d\n",
@@ -308,8 +299,6 @@ static void IRQ_check(OpenPICState *opp, IRQ_queue_t *q)
}
}
}
-
-out:
q->next = next;
q->priority = priority;
}
This reverts commit a9bd83f4c65de0058659ede009fa1a241f379edd. This counting approach is not robust against setting a bit that was already set, or clearing a bit that was already clear. Perhaps that is considered a bug, but besides the lack of any documentation for that restriction, it's a pretty unpleasant way for the problem to manifest itself. It could be made more robust by testing the current value of the bit before changing the count, but a later patch speeds up IRQ_check in all cases, not just when there's nothing pending. Hopefully that should be adequate to address performance concerns. Signed-off-by: Scott Wood <scottwood@freescale.com> --- hw/openpic.c | 11 ----------- 1 file changed, 11 deletions(-)