[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] sdhci: add quirk property for card insert inter
From: |
Andrew Baumann |
Subject: |
Re: [Qemu-devel] [PATCH] sdhci: add quirk property for card insert interrupt status on Raspberry Pi |
Date: |
Mon, 4 Jan 2016 22:12:20 +0000 |
> From: Peter Crosthwaite [mailto:address@hidden
> Sent: Thursday, 31 December 2015 21:38
> On Thu, Dec 31, 2015 at 1:40 PM, Andrew Baumann
> <address@hidden> wrote:
> > This quirk is a workaround for the following hardware behaviour, on
> > which UEFI (specifically, the bootloader for Windows on Pi2) depends:
> >
> > 1. at boot with an SD card present, the interrupt status/enable
> > registers are initially zero
> > 2. upon enabling it in the interrupt enable register, the card insert
> > bit in the interrupt status register is immediately set
> > 3. after a subsequent controller reset, the card insert interrupt does
> > not fire, even if enabled in the interrupt enable register
> >
>
> This is a baffling symptom. Does prnsts card ejection state fully work
> with physical card ejections and insertions both before and after the
> subsequent controller reset?
I just tested this, by polling prnsts and intsts in a tight loop at board
startup. At power on with a card inserted, prnsts reads 1FFF0000. Subsequent
removal of the card, re-insertion etc. does not change its value. After
enabling interrupts, I reliably see a card insert interrupt in intsts. If I
then write zero to the interrupt enable register, the pending card insert
interrupt remains, which seems to dispel the "mask on read" theory. Once acked
or reset, the card insert interrupt never recurs. I never saw a card removal
interrupt.
I did once see a card interrupt (0x100, i.e. the one that comes from the card
itself, not the controller) after re-inserting the card, but I think that's
irrelevant.
It's impossible to boot the Pi without having a card inserted (well, maybe with
a jtag debugger), but I did try inserting the card around 0.5s after applying
power, and the results were the same.
So, without the prnsts bits, I can't confirm or deny your theory about
debouncing logic, but either way there is a reliable ghost of a card insertion
interrupt that is signalled at power on, and remains pending until it is either
acked or the controller reset, after which point it never recurs. And I'd
really like to model that somehow without making a mess of sdhci.c :) Any ideas?
Andrew