On Wed, 4 Sep 2019 at 17:23, Damien Hedde <damien.he...@greensocs.com> wrote: > > In the raspi machine, the sd card can be on several sd bus (in reality > there is one bus but several controllers). It is initially created in > the "sd-bus" child in the gpio peripheral. Then is moved (parent bus > changes) during machine reset in the "sdhci-bus". It can be moved again > by software between the "sdhci-bus" and another bus ("bcm2835-sdhost-bus"). > Here's the corresponding qbus tree of the raspi machine: > + sysbus > * bcm2835_gpio > + sd-bus > * sd-card > * bcm2835-sdhost > + bcm2835-sdhost-bus > * generic-sdhci > + sdhci-bus > > During the initial machine reset, the sd card is moved. Since reset is > based on qbus tree, moving the card during the reset seems odd (it changes > the qbus tree). In this case, because of the order the qbus tree is > walked, the sd card ends up being reset twice; the effective reset order call > follows: > 1 sd-card > 2 sd-bus > 3 bcm2835_gpio -> move the sd-card to sdhci_bus > 4 bcm2835-sdhost-bus > 5 bcm2835-sdhost > 6 sd-card (again) > 7 sdhci-bus > 8 generic-sdhci > > This patch adds a raspi machine reset method which moves the sd card > to the sdhci-bus before doing the whole reset (which will try to do the > move too). By anticipating the move we avoid changing the qdev tree while > resetting it. > > In consequence the step 1 is skipped in the previous list: when reset starts > the sd-card is already not a child of bcm2835_gpio.
The solution proposed in this patch pushes something that should really be the business just of the SoC model out to the machine model level; it would be nice to be able to avoid that. thanks -- PMM