On 2011-09-12 14:54, Jan Kiszka wrote:
> On 2011-09-12 12:50, Avi Kivity wrote:
>> From: Richard Henderson <r...@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
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
