Re: [Qemu-devel] [PATCH] sdhci: add quirk property for card insert interrupt status on Raspberry Pi

[Andrew Baumann]

> From: Peter Crosthwaite [mailto:address@hidden
> Sent: Thursday, 7 January 2016 01:31
> On Tue, Jan 5, 2016 at 10:36 AM, Andrew Baumann
> <address@hidden> wrote:
[...]
> Are there any issues with rPI WP bit?

It's documented as reserved and appears permanently set to 1, but there's no 
obvious way for me to test it since micro SD cards don't have R/O lock 
switches. I think the present behaviour is fine.

> >> Your patch as-is here doesn't seem to address the penning behaviour
> >> (where the interrupt status remains clear until it is enabled), maybe
> >> that can be added as a second quirk if needed later?
> >
> > My second patch does handle this in a way that's good enough to boot
> UEFI: a card insert interrupt is pending at power on, and goes away on
> enable/ack or reset. However, it deviates from the hardware in that disabling
> an interrupt (intstsen) implicity masks it out from the intsts (and this is 
> true
> for any interrupt, not just card insertion). I think the "right" thing to do 
> would
> be to add a bool to the controller state to explicity track the pending card
> insert interrupt, and check it (under a quirk property) when the interrupt
> changes from disabled->enabled. Do you concur?
> >
> 
> Yes I think we need a separate new quirk for the bool for the penning.
> 
> The experimental results indicate that the device is completely
> unresponsive to a run-time ejection or insertion event. This suggest
> that we should follow through with more work on the no_eject quirk to
> get the modelling right, but I guess the bool patch and the revert can
> be a self contained first step and try again later with the no_eject
> quirk.
> 
> When you add the penning bool, you will get a new penned insertion
> event after the run-time reset. As long as your guest can handle this
> (a generic driver should be able to as the card is actually inserted)
> it should work fine.

My guest (Windows/UEFI) can't handle this :( I will need to ensure that it is 
really once-only, and not re-issued on the controller reset.

I'll send a new patch for this in the next few days.

Thanks,
Andrew