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

[Shanker Donthineni <shankerd@codeaurora.org>]

Eric/Alex,

Seems everyone was agreed, and add support for a generic vfio platform 
device class. I'm going to drop this HIDMA patch since the new generic 
vfio platform device class will cover.

Shanker

On 08/19/2016 06:43 AM, Auger Eric wrote:
> Hi Alex,
>
> On 19/08/2016 00:35, Alexander Graf wrote:
>>> On 18 Aug 2016, at 05:37, Auger Eric <eric.auger@redhat.com> 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 <vikrams@codeaurora.org>
>>>> Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
>>>> ---
>>>> 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
>>

-- 
Shanker Donthineni
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.