On 4 January 2017 at 22:06, Jean-Christophe Dubois <j...@tribudubois.net> wrote:
> The i.MX SPI device was not de-asserting the CS line at the end of
> memory access.
>
> This triggered a SIGSEGV in Qemu when the sabrelite emulator was acessing
> a SPI flash memory.
>
> Whith this path the CS signal is correctly asserted and deasserted arround
> memory access.
>
> Assertion level is now based on SPI device configuration.
>
> This was tested by:
> * booting linux on Sabrelite Qemu emulator.
> * booting xvisor on Sabrelite Qemu emultor.
>
> Signed-off-by: Jean-Christophe Dubois <j...@tribudubois.net>
> Acked-by: Marcin Krzemiński <mar.krzemin...@gmail.com>
> static void imx_spi_reset(DeviceState *dev)
> {
> IMXSPIState *s = IMX_SPI(dev);
> + uint32_t i;
>
> DPRINTF("\n");
>
> @@ -243,6 +263,11 @@ static void imx_spi_reset(DeviceState *dev)
> imx_spi_update_irq(s);
>
> s->burst_length = 0;
> +
> + /* Disable all CS lines */
> + for (i = 0; i < 4; i++) {
> + qemu_set_irq(s->cs_lines[i], !imx_spi_channel_pol(s, i));
> + }
Calling qemu_set_irq() in a device reset function is a bit
tricky, because in a full system reset the device at the other
end might have already reset or might not, and calling into
its handler function for the irq line change might provoke
an unwanted change of its state. We don't really have a coherent
model here but for the moment we just try to avoid calling
set_irq in a reset method.
thanks
-- PMM
