Date:	Mon, 23 Sep 2013 15:10:11 +0200
From:	Michal Simek <monstr@...str.eu>
To:	Jason Gunthorpe <jgunthorpe@...idianresearch.com>
CC:	Yves Vandervennet <rocket.yvanderv@...il.com>,
	Alan Tull <atull@...era.com>,
	Jason Cooper <jason@...edaemon.net>,
	Michal Simek <michal.simek@...inx.com>,
	linux-kernel@...r.kernel.org, Pavel Machek <pavel@....cz>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dinh Nguyen <dinguyen@...era.com>,
	Philip Balister <philip@...ister.org>,
	Alessandro Rubini <rubini@...dd.com>,
	Mauro Carvalho Chehab <m.chehab@...sung.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Cesar Eduardo Barros <cesarb@...arb.net>,
	Joe Perches <joe@...ches.com>,
	"David S. Miller" <davem@...emloft.net>,
	Stephen Warren <swarren@...dia.com>,
	Arnd Bergmann <arnd@...db.de>,
	David Brown <davidb@...eaurora.org>,
	Dom Cobley <popcornmix@...il.com>
Subject: Re: [RFC PATCH] fpga: Introduce new fpga subsystem

On 09/19/2013 07:28 PM, Jason Gunthorpe wrote:
> On Thu, Sep 19, 2013 at 10:18:03AM -0500, Yves Vandervennet wrote:
>> On Thu, Sep 19, 2013 at 5:55 AM, Michal Simek <monstr@...str.eu> wrote:
>>
>>>> Is there some way a per-device userspace helper can be added that can
>>>> handle adding the headers?  Such that different fpga types get different
>>>> helpers?
>>>
>>> What do you exactly mean by that? Any example what do you want to achieve?
>> Bit streams may not be in raw format, so using 'cat' is not possible.
>> Xilinx and Altera have their own bit stream "richer" format, that need
>> to be processed before they are presented to the driver(s). So, a
>> hotplug helper per manufacturer/FPGA is required. Assuming 'cat' will
>> be used is too limiting.
>> Does it make sense to you?
> 
> IMHO it doesn't make sense to use request firmware for this, in
> general.

If this is not the best way for you than fine just don't use it.

As I wrote I see a value to have sysfs bin file for this and
you don't need to use this request firmware interface.

> 
> 1) The driver doesn't know what firmware to request. It just knows
>    how to send it to a FPGA.

But dts property in the manager driver which uses this as end driver
can know that.

> 2) Telling the kernel a filename via sysfs and then having it go
>    around the long way via request_firwmare to get the data is silly.
>    Just give the kernel the actual data instead of a file name

Firmware interface is valid way how to pass bitstream to the kernel.
If you don't like just don't use it. For example you can add firmware blob directly
to the kernel and load this at bootup phase without user-space access.


> 3) It is hard to use, when userspace writes the file name the kernel
>    doesn't return until request_firmware completes, which means you
>    need multiple threads in user space to make this work.

that's again and again.

> 4) Converting an input file into bitstreamable format should be done
>    in userspace. This doesn't require request_firmware. If you want
>    to make it automatic then a program invoked via udev is the way
>    to go.

why are you restricting who should do this work? From my point of view
you are just pushing to have open way how to do it from user space
and there will be this option. But don't try to restrict others
if they want to do it just in the kernel in early phase.

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




Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)

Powered by blists - more mailing lists