Re: [Qemu-devel] PL353 Device model

[Peter Crosthwaite]

Thanks for you thoughts Andreas,

On Thu, Apr 5, 2012 at 9:56 AM, Andreas Färber <address@hidden> wrote:
> Hello John,
>
> Am 05.04.2012 01:35, schrieb John Williams:
>> On Fri, Mar 30, 2012 at 5:13 PM, Peter Crosthwaite
>> <address@hidden> wrote:
>>
>>> We currently have a somewhat hacky PL353 device model in our tree that
>>> we wish to refactor and ultimately push to mainline. Before I go about
>>> reworking it, I wish to discuss the architecture of this device model
>>> because its non-trivial.
>>
>> Ping..
>>
>> We'd really appreciate some feedback on this to avoid the duplicated
>> effort we are seeing in other areas such as SPI.
>
> Generally speaking, the qdev busses (i.e., tree-style) are scheduled to
> die out in favor of DAG-style QOM. However that's not going to happen
> for 1.1 yet, so if there's a need for a new SPI bus it needs to be qdev.
>
> As for the desired cascading here, my idea would be to make both flash
> interfaces child<>s of the controller,

Ok, i think step one is getting that pflash interface off the main
memory region then and having it in the device model. Two approach to
machine setup here tho, should the machine model hand off the flash
device to the pl353 is some way, or should the pl353 expose that
subregion to the machine model? Im personally thinking the former?

 arranging their MemoryRegions so
> that (if applicable) they become subregions and can be toggled by the
> controller.

One thing to consider tho, that there currently is no SRAM style NAND
implementation like there is for pflash, so the nand flash memory
region would be implemented from withing the pl353 itself. Basically
the pl353 would be talking to itself using mem api if you wanted to
get that kind of symmetry between the two interfaces.

Regards,
Peter

>
> My .02 AUD,
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg