Re: [Qemu-devel] [PATCH v3 5/7] STM32F205: Connect the ADC devices

[Alistair Francis]

On Tue, Feb 2, 2016 at 7:27 AM, Peter Maydell <address@hidden> wrote:
> On 19 January 2016 at 07:23, Alistair Francis <address@hidden> wrote:
>> Connect the ADC devices to the STM32F205 SoC.
>>
>> Signed-off-by: Alistair Francis <address@hidden>
>> ---
>> V2:
>>  - Fix up the device/devices commit message
>>
>>  hw/arm/stm32f205_soc.c         | 22 ++++++++++++++++++++++
>>  include/hw/arm/stm32f205_soc.h |  3 +++
>>  2 files changed, 25 insertions(+)
>>
>> diff --git a/hw/arm/stm32f205_soc.c b/hw/arm/stm32f205_soc.c
>> index a2bd970..28d4301 100644
>> --- a/hw/arm/stm32f205_soc.c
>> +++ b/hw/arm/stm32f205_soc.c
>> @@ -32,9 +32,12 @@ static const uint32_t timer_addr[STM_NUM_TIMERS] = { 
>> 0x40000000, 0x40000400,
>>      0x40000800, 0x40000C00 };
>>  static const uint32_t usart_addr[STM_NUM_USARTS] = { 0x40011000, 0x40004400,
>>      0x40004800, 0x40004C00, 0x40005000, 0x40011400 };
>> +static const uint32_t adc_addr[STM_NUM_ADCS] = { 0x40012000, 0x40012100,
>> +    0x40012200 };
>>
>>  static const int timer_irq[STM_NUM_TIMERS] = {28, 29, 30, 50};
>>  static const int usart_irq[STM_NUM_USARTS] = {37, 38, 39, 52, 53, 71};
>> +#define ADC_IRQ 18
>
> Really three devices but only one IRQ ?

Yep, that's how HW does it. At least according to the reference manual.

>
>> +    /* ADC 1 to 3 */
>> +    for (i = 0; i < STM_NUM_ADCS; i++) {
>> +        dev = DEVICE(&(s->adc[i]));
>> +        object_property_set_bool(OBJECT(&s->adc[i]), true, "realized", 
>> &err);
>> +        if (err != NULL) {
>> +            error_propagate(errp, err);
>> +            return;
>> +        }
>> +        busdev = SYS_BUS_DEVICE(dev);
>> +        sysbus_mmio_map(busdev, 0, adc_addr[i]);
>> +        sysbus_connect_irq(busdev, 0, qdev_get_gpio_in(nvic, ADC_IRQ));
>
> You can't just wire multiple irq lines up like this; I think if
> you do then if devices A and B both assert the IRQ and then A
> deasserts it, then the receiving device will see an IRQ deassert
> when it should not (since B still holds it high).

I can't figure out if that is how HW actually does it. I can't find
too much in the data sheet on how these interrupts behave.

In saying that, I am fine with what you described being the behaviour.
I don't know any better way to connect the 3 devices to one interrupt
line. Do you have any suggestions?

Thanks,

Alistair

>
> thanks
> -- PMM