On 17/03/15 21:53, Greg KH wrote:
> On Tue, Mar 17, 2015 at 09:46:13PM +0000, Malte Vesper wrote:
>>
>> On 17/03/15 21:13, Greg KH wrote:
>>> On Tue, Mar 17, 2015 at 08:43:38PM +0000, Malte Vesper wrote:
>>>> Hi,
>>>> I am trying to write a driver that uses the MINOR(dev_t) to identify
>>>> cards. Since it is a PCI driver and I get pcidev->dev.dev_t anyway. I
>>>> thought about not bothering to store the minor number of the device.
>>>> However if I look at pcidev->dev.dev_t in the remove function (the
>>>> driver frameworks remove), I always get pcidev->dev.dev_t == 0.
>>> That dev_t is not for your use, sorry, it is for the driver core to use,
>>> if it needs/wants to for a class device. A PCI driver should never need
>>> to be a char device, but if it does, you have to make your own calls to
>>> the character device core.
>>>
>>> What type of PCI device is this? Why do you want to have a character
>>> device node for it?
>>>
>>> thanks,
>>>
>>> greg k-h
>> I want to do stream processing with a FPGA. I hoped that I could read the
>> minor from that field after calling device_create().
> Yes, you can, but that's not what your pci device uses, you have to
> create your own device to be able to use that. And your driver should
> never need/care about what the minor number really is if you write it
> correctly :)
I only care about the minor to call device_destroy.
Also I thought it would be a nice way to ID the actual instance of the
device (I want to support multiple FPGAs, and figured I get the minor
from IOCTL calls for free).
If there is a driver that has a good way of doing it a pointer would
help so I could look at the code.
>
>> As for the streaming bit the intended mode of operation is send a chunk,
>> receive a processed chunk. Since the FPGA might do filtering the result
>> might be smaller.
>> Also there is no random access, and once a bit of the returned data has been
>> read, it can not be read again. The FPGA is more or less passthrough with
>> some FIFO buffers.
> Then why not just use the firmware interface for this instead?
>
>> This use model and other examples (there are a few PCIe FPGA drivers out
>> there which do char device (i.e. Riffa)), led me to pick a char device.
>> Either way, the actual data transfer is handled solely by the device acting
>> as a bus master (DMA).
>>
>> Would you still recommend a block device driver type?
> Firmware :)
From a quick google glance and my understanding of firmware I
understand the firmware interface as "Load this program on the devices
microcontroller".
The usage model I envision is more like: FPGA implements filter: Returns
all entries from a list which have a key greater threshold. So I need to
tell the driver 1) get list from memory here 2) put result in memory at
location 2.
If firmware is still better and I missunderstand it I will further read
up on it. (That would be one of the cases where one needs to know which
parts of the fine "manual" are relevant)
>
>> Is there an elegant way to get back at the MINOR() without storing it i.e.
>> in the private data field (pci_set_drvdata).
> Why do you need to know the minor? And again, please keep your pci
> device separate from anything that you try to create. You don't own the
> lifecycle of the pci device, the pci core does.
I feel I fail to grasp the meaning of this with my limited insight. I
figured that the PCI core would ensure that remove is called (after all
I suppy it a struct pci_driver, so that I can define the add/remove work
needed). Why is it wrong to try (well it does not work, but I can't
quite see why it should be 0 after calling device_create succesfully):
static void remove(struct pci_dev *pcidev) {
...
device_destroy(FPCI3.class, pcidev->dev.devt);
...
}
I understand (from your earlier mail) that the pci framework does not
touch pcidev->dev.devt, since it uses its own identifier.
>
> Also, there's a long-standing discussion of a "real" fpga kernel
> interface on the linux-kernel mailing list. I suggest reading the
> archives for it, and joining if you want to help create something that
> works for your card.
I will have a look. Thanks for the pointer and insights,
Malte
>
> thanks,
>
> greg k-h
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
