On 07/23/2015 11:20 PM, atull wrote:
> On Thu, 23 Jul 2015, Christoph Lameter wrote:
> 
>> On Thu, 23 Jul 2015, Linus Walleij wrote:
>>
>>>>>> People that might be interested:
>>
>> I would be very very interested in the subject matter. Anything that helps
>> creating some abstraction layer that allows the open source development of
>> tools on top.
>>
>> _______________________________________________
>> Ksummit-discuss mailing list
>> Ksummit-discuss@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>>
> 
> Jason is another person who may be interested in this topic:
> Jason Gunthorpe = jgunthorpe at obsidianresearch.com
> 
> My work has been to get a uniform API for FPGA programming into the
> kernel along with an interface for controlling reprogramming.  My
> current patchset separates the two so that if the interface I am
> proposing doesn't meet somebody's use needs, another interface
> can be written to use the API functions.
> 
> http://marc.info/?l=linux-kernel&m=143714949226387&w=2
> 
> Topics that have been discussed in the mailing list could be included 
> here:
> 
>  * At least two different basic use models:
>    * FPGA as hardware (containing harware devices that need drivers)
>    * FPGA as accelerator.  If FPGA is an accelerator, it could be
>      allocated in a malloc-like thing - Alan Cox's proposal.
>  * Device Tree Overlays as an interface in the "FPGA as Hardware" use,
>    where loading an overlay will cause FPGA reconfiguration, bridges
>    getting enabled, and devices being created, drivers probed.  The
>    code for accomplishing all this is actually quite small.
>  * Some use cases are complicated systems that need a lot of userspace
>    to bring things up in a sequenced way (may need another interface
>    with lots of userspace control and FPGA status available to
>    userspace).
>  * Security issues that arise if FPGA programming can be controlled
>    from userspace.
>  * How to control the bridges. Some hardware needs the bridges disabled
>    during FPGA programming.  How to conceptualize this in the device tree.
>  * It is likely that these different use cases will best be suited by
>    different interfaces.

user space part is probably the most problematic topic which needs to be
discussed.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform