Re: [RFC] dmaengine: vdma: Add support for platform data

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

 



On 06/13/2016 07:00 PM, Vinod Koul wrote:
> On Mon, Jun 13, 2016 at 05:01:53PM +0100, Jose Abreu wrote:
>> Hi Vinod,
>>
>> Thanks for your answer!
>>
>>
>> On 13-06-2016 06:30, Vinod Koul wrote:
>>> On Thu, Jun 09, 2016 at 04:48:38PM +0100, Jose Abreu wrote:
>>>> Hi all,
>>>>
>>>> Currently I am using Xilinx VDMA in a FPGA that is connected to a
>>>> x64 platform using PCIe. As x64 does not use device tree I needed
>>>> to add support for platform data in the Xilinx VDMA driver. Do
>>>> you think that this change can be a submittable patch to
>>>> mainline? The patch is fairly simple but it was made against the
>>>> previous version of the driver that only supports AXI VDMA. I've
>>>> seen that support for AXI DMA and AXI CDMA was recently added so
>>>> the patch needs to be rebased.
>>>>
>>>> My main doubt about this being submittable is because I really
>>>> don't know how the use of platform data is seen by you guys so I
>>>> would really appreciate some feedback about this.
>>> Platform data should be okay, but who will initialize that?
>>
>> In my setup I am using a PCI driver that populates the platform
>> data structure and registers the VDMA driver.
>>
>>>
>>> Shouldn't your device be a ACPI device?
>>
>> Well, I am not very familiar with ACPI but for what I've read it
>> is not applicable in this case because the VDMA device is not
>> inherently discoverable by PCI. It is connected to the PC using
>> PCIe which in turn connects to the FPGA. The host knows it has a
>> PCI device but the device itself is composed by many sub-blocks
>> (vdma, video timing controller, HDMI Phy, ...). Besides, the ACPI
>> tables are hardcoded into the BIOS, right? If yes, then I think
>> it is not an ideal solution.
> 
> ACPI is quite like DT for x86!
> 
> ACPI has device tables which describe the devices which are not
> discoverable. (not everything in x86 is discoverable)
> 
> Yes these are hard coded in BIOS, but if you are connecting
> FPGA and providing additional functionality then BIOS update would be
> required to describe all these

The FPGA is on a PCIe card. PCIe cards are autodetected and not hardcoded in
the BIOS table.

For this problem there are basically two approaches.

1) Extend all used drivers for the used peripherals with platform data
support. Then write a PCIe driver which instantiates all the drivers for the
peripherals found on the board and in the FPGA using platform devices and
platform data.

2) Use DT overlays. This does not require any changes to any of the existing
peripheral drivers already supporting DT. The way this works is you create a
DT snippet that describes the peripherals on your PCIe card and then write a
simple PCIe driver that loads the DT blob for said snippet when the card is
detected.

This does not yet work in the upstream kernel, but it is the preferred
approach and multiple people are working on getting a solution for this
upstream. E.g. see https://github.com/mfornero/linux/commits/dtbo_wip

- Lars
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux PCI]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux