Re: [PATCH v2 2/3] fpga manager: framework core

[Michal Simek <monstr@monstr.eu>]

[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]

On 12/09/2014 02:11 PM, Grant Likely wrote:
> On Mon, Dec 8, 2014 at 10:55 PM, One Thousand Gnomes
> <gnomes@lxorguk.ukuu.org.uk> wrote:
>> On Sat, 6 Dec 2014 13:00:17 +0000
>> Grant Likely <grant.likely@linaro.org> wrote:
>>
>>> On Fri, Oct 24, 2014 at 11:52 AM, Pavel Machek <pavel@denx.de> wrote:
>>>> Hi!
>>>>
>>>>> * /sys/class/fpga_manager/<fpga>/firmware
>>>>>   Name of FPGA image file to load using firmware class.
>>>>>   $ echo image.rbf > /sys/class/fpga_manager/<fpga>/firmware
>>>>
>>>> I .. still don't think this is good idea. What about namespaces?
>>>> The path corresponds to path in which namespace?
>>>
>>> I don't understand your concern here. This allows userspace to name
>>> the FPGA bitstream that the kernel will use during request_firmware(),
>>> and it will show up as the $FIRMWARE value in the uevent file, but it
>>> is still the responsibility of userspace to choose what to load, and
>>> it can freely ignore the setting of $FIRMWARE if it needs to.
>>
>> I think the entire model here is basically pedicated on a bogus
>> assumption that an FPGA is a one shot device. It's not. It's a fast
>> reloadable reusable device. A lot of work being done with FPGAs in
>> operating systems already involves basically task switching and
>> scheduling FPGAs as a shared resource pool. Trying to nail something
>> together with request_firmware is several years behind the curve.
>>
>> From userspace it needs to be a open, load, use, close type model, not a
>> static or semi-static pile of mappings.
> 
> If FPGA is a general purpose resource hanging off the side that
> applications can use, then sure, but the majority of FPGA usage does
> not fall into that scenario*. The majority of FPGA usage that I've
> seen has core parts of the system implemented in the FPGA fabric.
> Video pipelines, network switching, dma to/from main memory, control
> of dedicated hardware. It's more than merely an application being able
> to use the FPGA as an accelerator.
> 
> I'm certainly not dismissing the concept of FPGA scheduling and being
> able to 'task switch' between bitstreams. Yes that is important, but
> for most users it really does look like, as you say, "a static or
> semi-static pile of mappings".
> 
> * Altera and Xilinx people - correct me if you disagree.

We need to start to walk before we can run. We should move the part of this
patch series to drivers/staging directory. Greg is OK with that and
start to adding drivers for current drivers.
Static use case is good start and we should move forward not to stay in circle.

I have some changes to this series internally which should be done.
Please give me some days to finish other work and we can move.

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]