On 7/31/19 5:45 PM, Philippe Mathieu-Daudé wrote:
> On Wed, Jul 31, 2019 at 5:43 PM Philippe Mathieu-Daudé
> <phi...@redhat.com> wrote:
>> On 7/31/19 4:21 PM, Damien Hedde wrote:
>>> Concerning the reset on the raspi2/3 machine, I ran into an issue with
>>> the sd-card.
>>>
>>> Here follows a subset of the qbus/qdev tree of the raspi2&3 machine as
>>> it is initialized:
>>> + System
>>> * bcm2835_gpio
>>> + sd-bus
>>> * sd-card
>>> * bcm2835-sdhost
>>> + bcm2835-sdhost-bus
>>> * generic-sdhci
>>> + sdhci-bus
>>>
>>> raspi_init does 2 things:
>>> + it creates the soc
>>> + then it explicitly creates the sd-card on the bcm2835_gpio's sd-bus
>>>
>>> As it happens, the reset moves the sd-card on another bus: the
>>> sdhci-bus. More precisely the bcm2835_gpio reset method does it (the
>>> sd-card can be mapped on bcm2835-sdhost-bus or sdhci-bus depending on
>>> bcm2835_gpio registers, reset configuration corresponds to the sdhci-bus).
>>>
>>> Reset call order is the following (it follows children-before-parent order):
>>> 1 sd-card
>>> 2 sd-bus
>>> 3 bcm2835_gpio -> move the sd-card
>>> 4 bcm2835-sdhost-bus
>>> 5 bcm2835-sdhost
>>> 6 sd-card (again)
>>> 7 sdhci-bus
>>> 8 generic-sdhci
>>>
>>> In the end, the sd-card is reset twice, which is no big-deal in itself.
>>
>> The machine cold reset implicitly cold resets the sd-card.
>>
>> IIRC the sd-bus shouldn't (cold/warm)-reset the sd-card.
>>
>> Only SDBusClass::set_inserted() can cold-reset the card.
I agree but it's something we cannot address until the reset propagation
is hard-coded to be qdev/qbus based.
>>
>>> But it only depends on the bcm2835_gpio tree being reset before the
>>> generic-sdhci (probably depends on the machine creation code).
>>>
>>> I checked and it seems this is the only platform where such things
>>> happen during master reset.
>>>
>>> IMO this is a bit hazardous because reset is based on the qdev/qbus
>>> tree (and with the multi-phase I'm working on, even if it still works,
>>> it's worse).
>>> I'm not sure what we should do to avoid this (and if there's is
>>> something to be done).
>>>
>>> The easiest solution would be to initialize the platform with the
>>> sd-card at the right initial place (I do not really understand why it is
>>> created in the bcm2835_gpio in the first place since we move it just
>>> after). But it won't solve the issue if a reset is done afterwards.
>>>
>>> Or maybe we could move the sd-card on the proper bus in a machine
>>> reset code so that it's on the right place when we do the sysbus tree
>>> reset just after.
>>>
>>> What do you think ?
>>
>> There is only 1 bus, the SDHCI bus lines are muxed with the GPIO ones.
>>
>> bcm2835-sdhost-bus should not be child of bcm2835-sdhost, the sdbus
>> might be child of bcm2835-peripherals and shared by both sdhost and gpio
>> (as a link property?).
>
> There is a similar modelling issue with the AUX uart and SPI on this device.
>
>> I tried to do that 2 years ago. I thought I posted the series and Peter
>> rejected it but can't find it, maybe we had an IRC chat. I won't have
>> time until next week to dig for it.
I was thinking of doing a work-around by defining the raspi machine
reset to something like that.
static void raspi_reset(MachineState *machine)
{
SDBus *sdhci, *sdhost, *sdbus;
/*
* anticipate following reset and ensure the sd-card at its
* end-of-reset place
*/
sdhci = object_resolve_path("/path/to/sdhci");
sdhost = object_resolve_path("/path/to/sdhost");
sdbus = object_resolve_path("/path/to/sdbus");
sdbus_reparent_card(sdbus, sdhci); // no-op if card is not on sdbus
sdbus_reparent_card(sdhost, sdhci); //no-op if card is not on sdhost
/* standard reset */
qemu_devices_reset();
}
Damien
