diff options
author | Peter Maydell <peter.maydell@linaro.org> | 2021-07-02 11:40:18 +0100 |
---|---|---|
committer | Peter Maydell <peter.maydell@linaro.org> | 2021-07-09 16:09:12 +0100 |
commit | 5092e014f4dd6a0174e487741382053694527bc5 (patch) | |
tree | 8777c8de4e01e5aa45628a1952939f20072e1b9b /hw/arm | |
parent | 0642e159d2351a8fd7d03f78b5d97010cd514561 (diff) | |
download | qemu-5092e014f4dd6a0174e487741382053694527bc5.zip qemu-5092e014f4dd6a0174e487741382053694527bc5.tar.gz qemu-5092e014f4dd6a0174e487741382053694527bc5.tar.bz2 |
hw/arm/stellaris: Expand comment about handling of OLED chipselect
The stellaris board doesn't emulate the handling of the OLED
chipselect line correctly. Expand the comment describing this,
including a sketch of the theoretical correct way to do it.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Diffstat (limited to 'hw/arm')
-rw-r--r-- | hw/arm/stellaris.c | 56 |
1 files changed, 55 insertions, 1 deletions
diff --git a/hw/arm/stellaris.c b/hw/arm/stellaris.c index 8b4dab9..ad48cf2 100644 --- a/hw/arm/stellaris.c +++ b/hw/arm/stellaris.c @@ -1453,13 +1453,67 @@ static void stellaris_init(MachineState *ms, stellaris_board_info *board) DeviceState *sddev; DeviceState *ssddev; - /* Some boards have both an OLED controller and SD card connected to + /* + * Some boards have both an OLED controller and SD card connected to * the same SSI port, with the SD card chip select connected to a * GPIO pin. Technically the OLED chip select is connected to the * SSI Fss pin. We do not bother emulating that as both devices * should never be selected simultaneously, and our OLED controller * ignores stray 0xff commands that occur when deselecting the SD * card. + * + * The h/w wiring is: + * - GPIO pin D0 is wired to the active-low SD card chip select + * - GPIO pin A3 is wired to the active-low OLED chip select + * - The SoC wiring of the PL061 "auxiliary function" for A3 is + * SSI0Fss ("frame signal"), which is an output from the SoC's + * SSI controller. The SSI controller takes SSI0Fss low when it + * transmits a frame, so it can work as a chip-select signal. + * - GPIO A4 is aux-function SSI0Rx, and wired to the SD card Tx + * (the OLED never sends data to the CPU, so no wiring needed) + * - GPIO A5 is aux-function SSI0Tx, and wired to the SD card Rx + * and the OLED display-data-in + * - GPIO A2 is aux-function SSI0Clk, wired to SD card and OLED + * serial-clock input + * So a guest that wants to use the OLED can configure the PL061 + * to make pins A2, A3, A5 aux-function, so they are connected + * directly to the SSI controller. When the SSI controller sends + * data it asserts SSI0Fss which selects the OLED. + * A guest that wants to use the SD card configures A2, A4 and A5 + * as aux-function, but leaves A3 as a software-controlled GPIO + * line. It asserts the SD card chip-select by using the PL061 + * to control pin D0, and lets the SSI controller handle Clk, Tx + * and Rx. (The SSI controller asserts Fss during tx cycles as + * usual, but because A3 is not set to aux-function this is not + * forwarded to the OLED, and so the OLED stays unselected.) + * + * The QEMU implementation instead is: + * - GPIO pin D0 is wired to the active-low SD card chip select, + * and also to the OLED chip-select which is implemented + * as *active-high* + * - SSI controller signals go to the devices regardless of + * whether the guest programs A2, A4, A5 as aux-function or not + * + * The problem with this implementation is if the guest doesn't + * care about the SD card and only uses the OLED. In that case it + * may choose never to do anything with D0 (leaving it in its + * default floating state, which reliably leaves the card disabled + * because an SD card has a pullup on CS within the card itself), + * and only set up A2, A3, A5. This for us would mean the OLED + * never gets the chip-select assert it needs. We work around + * this with a manual raise of D0 here (despite board creation + * code being the wrong place to raise IRQ lines) to put the OLED + * into an initially selected state. + * + * In theory the right way to model this would be: + * - Implement aux-function support in the PL061, with an + * extra set of AFIN and AFOUT GPIO lines (set up so that + * if a GPIO line is in auxfn mode the main GPIO in and out + * track the AFIN and AFOUT lines) + * - Wire the AFOUT for D0 up to either a line from the + * SSI controller that's pulled low around every transmit, + * or at least to an always-0 line here on the board + * - Make the ssd0323 OLED controller chipselect active-low */ bus = qdev_get_child_bus(dev, "ssi"); |