Peter Crosthwaite writes:
> On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote:
>> Paolo Bonzini writes:
>>
>>> On 23/03/2015 10:10, Markus Armbruster wrote:
[...]
I believe the proper solution for your problem is qdevifying the SD
card.
>>>
>>> The question is whether there is
On 23/03/2015 16:01, Peter Crosthwaite wrote:
> Note that SD has a SPI mode, every SD card is in theory a valid SSI
> device. We could unify SD under SSI to achieve both QOMification and
> busification.
That wouldn't really be the way most SD cards work, anyway. The
protocol doesn't do simultan
On 23 March 2015 at 15:01, Peter Crosthwaite
wrote:
> On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote:
>> If sd.c is common code rather than a device model in its own right,
>> perhaps SDState should be unboxed in SDHCIState, just like the FDrive
>> are unboxed in FDCtrl. The "drive" pr
On Mon, Mar 23, 2015 at 7:05 PM, Markus Armbruster wrote:
> Paolo Bonzini writes:
>
>> On 23/03/2015 10:10, Markus Armbruster wrote:
>>> Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
>>> its realize() method. Is it the only device model with this issue?
>>
>> I think SD d
On 23/03/2015 14:35, Markus Armbruster wrote:
>>> From 30,000ft, this looks a bit like the floppy case: BB's dev points to
>>> the block device, and BB's dev_opaque points within the device.
>>>
>>> If you descend a bit, it looks a lot more like the usb-storage hack that
>>> has caused us nothing
Paolo Bonzini writes:
> On 23/03/2015 13:09, Peter Maydell wrote:
>> > The only alternative for 2.3 is reverting the patch for sdhci-pci. I
>> > certainly don't want "-drive if=sd -device sdhci-pci" to become ABI!
>>
>> What's wrong with that, incidentally? It's what I would have
>> expected for
Paolo Bonzini writes:
> On 23/03/2015 10:10, Markus Armbruster wrote:
>> Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
>> its realize() method. Is it the only device model with this issue?
>
> I think SD devices are the only ones, but all of them have the issue.
>
> Ironi
On 23/03/2015 13:09, Peter Maydell wrote:
> > The only alternative for 2.3 is reverting the patch for sdhci-pci. I
> > certainly don't want "-drive if=sd -device sdhci-pci" to become ABI!
>
> What's wrong with that, incidentally? It's what I would have
> expected for connecting an SD card to sdh
On 23 March 2015 at 12:05, Paolo Bonzini wrote:
>
> The only alternative for 2.3 is reverting the patch for sdhci-pci. I
> certainly don't want "-drive if=sd -device sdhci-pci" to become ABI!
What's wrong with that, incidentally? It's what I would have
expected for connecting an SD card to sdhci
On 23/03/2015 10:10, Markus Armbruster wrote:
> Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
> its realize() method. Is it the only device model with this issue?
I think SD devices are the only ones, but all of them have the issue.
Ironically, the qdevified ones call d
Paolo Bonzini writes:
> Add a drive property that can be used with sdhci-pci (instead of the odd
> "-drive if=sd,... -device sdhci-pci" that has no equivalent in the rest
> of QEMU).
Ugh. sdhci-pci is incorrectly qdevified: it uses drive_get_next() in
its realize() method. Is it the only devic
Add a drive property that can be used with sdhci-pci (instead of the odd
"-drive if=sd,... -device sdhci-pci" that has no equivalent in the rest
of QEMU). Then adjust the zynq platform to set it based on the DriveInfo
that it gets.
Note that in this case the BlockBackend is attached to the SDHCI
12 matches
Mail list logo
