qemu-arm
[Top][All Lists]
Advanced

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

Re: [Qemu-arm] [PATCH 4/8] bcm2835_emmc: add bcm2835 MMC/SD controller


From: Peter Crosthwaite
Subject: Re: [Qemu-arm] [PATCH 4/8] bcm2835_emmc: add bcm2835 MMC/SD controller
Date: Wed, 9 Dec 2015 13:38:06 -0800

On Wed, Dec 9, 2015 at 1:01 PM, Peter Maydell <address@hidden> wrote:
> On 9 December 2015 at 18:54, Peter Crosthwaite
> <address@hidden> wrote:
>> On Wed, Dec 9, 2015 at 10:17 AM, Andrew Baumann
>> <address@hidden> wrote:
>>>> From: Peter Crosthwaite [mailto:address@hidden
>>>> Is that more likely to be an IP connectivity problem (wierd input to
>>>> the card-detect pin in the SoC)?
>>>
>>> That might be it, but in any case I still need to model it somehow.
>>>
>>
>> Ideally, this would be managed on the board level but it is kinda hard
>> the way to code is organised. Currently SDHCI is managing the SD card
>> instantiation due to a lack of QOMification. So for the moment, this
>> would be valid as a boolean property which disables the card detect
>> logic completely. If we get the SD QOMification though, the power,
>> card detect and sd interface proper can then be more finely managed on
>> the board level for all these varying connectivity configurations.
>
> Card detect you should be able to handle on the board level without
> waiting for QOMification -- it's just modelled as a QEMU irq line
> (the vexpress board connects it up to a random register, or you could
> not connect it to anything, etc).
>

It's probably worth waiting for the QOMification though, so the GPIO
out has a correct formal owner.

> I'm working on the QOMification of sd.c this week, though I'm very
> rusty on how to properly model buses.
>

The last bus I did was SSI (SPI) which I am reasonably confident that
it is up to date unless we are trying to achieve the "busless" goal or
pure QOM links. When I was looking at NAND QOMification (unfortunately
I didn't make it to conclusion) I noticed that many of the features
were common to SSI, mainly WRT GPIO based individual chip select
lines. Since SD is has SPI compatibility mode an SD card should
actually be a subclass of SSI_DEVICE. I'm thinking the same might
apply on the bus side. So you could subclass SSI_BUS as SD_BUS which
picks up SSI's CS stuff for free while quite naturally having the
consequence of SD cards being SPI devices.

Regards,
Peter

> thanks
> -- PMM



reply via email to

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