Message ID | 4E6E010D.9030303@siemens.com |
---|---|
State | New |
Headers | show |
On 2011-09-12 14:54, Jan Kiszka wrote: > On 2011-09-12 12:50, Avi Kivity wrote: >> From: Richard Henderson <rth@twiddle.net> >> >> The only non-obvious part is pic_poll_read which used >> "addr1 >> 7" to detect whether one referred to either >> the master or slave PIC. Instead, test this directly. > > I've an unfinished queue here that, among other things, took some of > the PIC mess away via > > --- a/hw/ppc_prep.c > +++ b/hw/ppc_prep.c > @@ -129,7 +129,7 @@ static inline uint32_t _PPC_intack_read(target_phys_addr_t addr) > uint32_t retval = 0; > > if ((addr & 0xf) == 0) > - retval = pic_intack_read(isa_pic); > + retval = pic_read_irq(isa_pic); > #if 0 > printf("%s: 0x" TARGET_FMT_plx " <= %08" PRIx32 "\n", __func__, addr, > retval); > > I've found no regression in prep due to this and was able to kill both > pic_poll_read and pic_intack_read this way. > > I've no problem to (later on) rebase my PIC refactorings (properly > decouple both chips and qdev'ify them) on top of this, but maybe the > prep cleanup would already make this patch nicer. Should I break out > that patch? The patch is not that easy to break out as it depends on other changes, e.g. a fix for the broken poll command implementation in our i8259. That probably leads too far for this conversion. Jan
--- a/hw/ppc_prep.c +++ b/hw/ppc_prep.c @@ -129,7 +129,7 @@ static inline uint32_t _PPC_intack_read(target_phys_addr_t addr) uint32_t retval = 0; if ((addr & 0xf) == 0) - retval = pic_intack_read(isa_pic); + retval = pic_read_irq(isa_pic); #if 0 printf("%s: 0x" TARGET_FMT_plx " <= %08" PRIx32 "\n", __func__, addr, retval);