qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] hw/vfio/platform: Add Qualcomm Technologies,


From: Auger Eric
Subject: Re: [Qemu-devel] [PATCH v2] hw/vfio/platform: Add Qualcomm Technologies, Inc HIDMA device support
Date: Fri, 19 Aug 2016 13:43:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

Hi Alex,

On 19/08/2016 00:35, Alexander Graf wrote:
> 
>> On 18 Aug 2016, at 05:37, Auger Eric <address@hidden> wrote:
>>
>> Hi Shanker,
>>
>> Adding Alex in CC for (*)
>>
>> On 14/08/2016 17:42, Shanker Donthineni wrote:
>>> This patch introduces the Qualcomm Technologies, Inc HIDMA device and
>>> allows passthrough the host HIDMA device to a guest machine using the
>>> vfio-platform framework.
>>>
>>> A platform device tree node is created for the guest machine which
>>> contains the compat string 'qcom,hidma-1.0', mmio regions, active high
>>> SPIs, and an optional property dma-coherent.
>>>
>>> Signed-off-by: Vikram Sethi <address@hidden>
>>> Signed-off-by: Shanker Donthineni <address@hidden>
>>> ---
>>> Changes sicnce v1:
>>>  combined patches [v1 1/2] and [v1 2/2].
>> Some general comments:
>> - I preferred the previous series organization where we had the creation
>> of the VFIO device first and its sysbus-fdt dynamic instantiation in a
>> separate patch.
>>
>> Peter requested sysbus-fdt stops growing and advised to split the fine
>> into generic helpers and specific dt creation functions in separate
>> files. This sounds the right moment to do it with looming new VFIO devices.
>>
>> (*) Also I am now reconsidering the relevance of creating specific VFIO
>> devices per compat string. At the begining of VFIO QEMU integration
>> history we made that choice, advised by Alex (Graf), considering the
>> QEMU VFIO device could not be generic. With a little more experience now
>> we could see the specialization is currently done in the dt creation
>> function (sysbus-fdt) and in the kernel reset module. So I would now
>> advocate using a non abstract base VFIO device that could be
>> instantiated passing its compat string as property. Creating
>> hw/vfio/qcom-hidma.c and include/hw/vfio/vfio-qcom-hidma.h then would
>> become useless. Alex, what is your feeling now?
> 
> Back when we set up the rule we were concerned with a few things that a 
> generic sysbus devices can’t implement properly:
> 
>   * generic reset
>   * power control
>   * clock control
> 
> I guess the first two are mostly a matter of the in-kernel driver, not the 
> user space one. Clock control hopefully isn’t much of a thing with real 
> hardware ;).
> 
> So yes, if you can make a generic driver work, I’m not opposed.

Thank you for the confirmation!

Best Regards

Eric
> 
> 
> Alex
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]