qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PULL 15/28] i8259: Convert to MemoryRegion


From: Jan Kiszka
Subject: Re: [Qemu-devel] [PULL 15/28] i8259: Convert to MemoryRegion
Date: Mon, 12 Sep 2011 15:30:42 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

On 2011-09-12 14:54, Jan Kiszka wrote:
> On 2011-09-12 12:50, Avi Kivity wrote:
>> From: Richard Henderson <address@hidden>
>>
>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]