Date:	Tue, 04 Dec 2012 12:13:30 +0200
From:	Eli Billauer <eli.billauer@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	linux-kernel@...r.kernel.org, arnd@...db.de
Subject: Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA
 (programmable logic)

On 12/04/2012 05:41 AM, Greg KH wrote:
> On Sun, Dec 02, 2012 at 07:26:27PM +0200, Eli Billauer wrote:
>    
>> On 11/30/2012 06:32 PM, Greg KH wrote:
>>      
>>>>>>>   >>+static struct class *xillybus_class;
>>>>>>>                
>>>>>>   >Why not just use the misc interface instead of your own class?
>>>>>>              
>>>>>   When Xillybus is used, the whole system's mission is usually around
>>>>>   it (e.g. it's a computer doing data acquisition through the Xillybus
>>>>>   pipes). So giving it a high profile makes sense, I believe. Besides,
>>>>>   a dozen of device files are not rare.
>>>>>            
>>> It is no problem to create dozens of misc devices.  It makes your driver
>>> smaller, contain less code that I have to audit and you have to ensure
>>> you got right, and it removes another user of 'struct class' which we
>>> are trying to get rid of anyway.  So please, move to use a misc device.
>>>
>>>        
>> It has just occurred to me that DYNAMIC_MINORS is 64
>> (drivers/char/misc.c), so I guess that limits the number of misc
>> devices that can be generated, at least with dynamically allocated
>> minors. I previously mentioned "a dozen" as the number of devices,
>> but I've already run tests with 100+ devices, and I can also think
>> of a sane application for that.
>>
>>
>> So if I understood the situation correctly, it looks like using misc
>> devices will create a limitation which will be reached sooner or
>> later.
>>
>> Any suggestion what to do?
>>      
> Given that I don't really understand how you can have that many device
> nodes, because I don't know what they all seem to be needed for, I can't
> answer this question.
>
> Again, any hints on the user/kernel api you use/need here?  Does it
> really have to be device nodes?  What's wrong with the simple firmware
> interface the kernel provides?
>
>    
I'm currently writing some documentation which will cover the API and 
also help reading the code, I hope. It takes some time...

Until it's done, let's look at a usage example: Suppose that the FPGA's 
application is to receive a high-speed bitstream with time multiplexed 
data, demultiplex the bitstream into individual channel streams, and 
send each channel's data to the host. And let's say that there are 64 
channels in original bitstream. So the FPGA has now 64 independent 
sources of data.

For that purpose, the Xillybus IP core (on the FPGA) is configured to 
create 64 pipes for FPGA to host communication. The names of these pipes 
(say, "chan00", "chan01", ...) are also stored in the FPGA.

When the driver starts, it queries the FPGA for its Xillybus 
configuration, and creates 64 device nodes: /dev/xillybus_chan00, 
/dev/xillybus_chan01, ... /dev/xillybus_chan63.

If the user wants to dump the data in channel 43 into a file, it's just:

$ cat /dev/xillybus_chan43 > mydump.dat

I hope this clarified things a bit.

I can't see how the firmware interface would help here.

Regards,
     Eli
> thanks,
>
> greg k-h
>
>    


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists