Rafael and Mika has interest in this topic, so am adding them for the discussion. On Wed, Jun 15, 2016 at 10:36:57AM +0100, Jose Abreu wrote: > 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. That is also true, but for those cases, you can patch DSDT and test. Kernel provides ways to load your own DSDT and we frequently use that! > >> 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? The platform data approach is _not_ scalable, so I am not convinced we should do that. -- ~Vinod -- 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
