Hi, Thank you all for your comments. On 14-06-2016 17:44, Lars-Peter Clausen wrote: > On 06/14/2016 06:42 PM, Vinod Koul wrote: >> On Tue, Jun 14, 2016 at 11:02:29AM +0200, Lars-Peter Clausen wrote: >>>> ACPI has device tables which describe the devices which are not >>>> discoverable. (not everything in x86 is discoverable) >>>> >>>> Yes these are hard coded in BIOS, but if you are connecting >>>> FPGA and providing additional functionality then BIOS update would be >>>> required to describe all these >>> The FPGA is on a PCIe card. PCIe cards are autodetected and not hardcoded in >>> the BIOS table. >> Can we detect the devices on the FPGA as well, my guess is No. >> And isn't the BIOS updated for FPGAs? BIOS tables are per board, same as DT >> entries you would write for a card. > This is not any different from any PCI(e) card with ASICs on it. You can't > autodiscover what is on the PCI(e) card. The card has a vendor and device ID > which are used to match a driver to the card and the driver knows what is on > the card and writes the right registers, maps the interrupts and so on. Yes, this is also true in my case. The FPGA itself is the discoverable device but we can't know what devices are inside of it. The PCI driver is responsible to know what devices are present and initialize the required drivers. > >> Even for discoverable devices, DSDT provides methods to read data. >> >>> For this problem there are basically two approaches. >>> >>> 1) Extend all used drivers for the used peripherals with platform data >>> support. Then write a PCIe driver which instantiates all the drivers for the >>> peripherals found on the board and in the FPGA using platform devices and >>> platform data. >> The problem with platform devices is that they require pdata and I do not >> see a scalable way to do pdata I am using this first option because I was not aware of the existence of DT overlays when I started this project and now is quite advanced so maybe only in the future we will change to the second option. >> >>> 2) Use DT overlays. This does not require any changes to any of the existing >>> peripheral drivers already supporting DT. The way this works is you create a >>> DT snippet that describes the peripherals on your PCIe card and then write a >>> simple PCIe driver that loads the DT blob for said snippet when the card is >>> detected. >>> >>> This does not yet work in the upstream kernel, but it is the preferred >>> approach and multiple people are working on getting a solution for this >>> upstream. E.g. see https://github.com/mfornero/linux/commits/dtbo_wip >> OTOH that does sounds bit better. But this also seems like shoving DT on >> x86, akin to someone forcing you to use ACPI as they have toolsets and >> prefer to use that. > ACPI is used for the description provided by the bios, this is a description > that is embedded within the kernel and specific to a particular driver, > using ACPI just makes it more complicated. Note that sometimes we test different bit files that have different blocks. The FPGA is only for prototyping so I also don't think programing the BIOS each time we use a different bit file is efficient instead of using one of the previous suggested options. > >> Finally as long as data is being discovered and not hard coded in kernel, I >> really don't mind either way! It just means to an end! > Well, which devices will be instantiated for a specific PCIe ID is still > hardcoded in the kernel. But rather than having a C file which registers > platform devices you have a device-tree which registers platform devices. @Vinod: Given these comments do you think it is worth sending the platform data patch? Best regards, Jose Miguel Abreu -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
