On 2019-06-07 1:17 p.m., Alexandru Ardelean wrote: > On Fri, Jun 7, 2019 at 10:33 AM Michal Simek <michal.simek@xxxxxxxxxx> wrote: >> >> On 06. 06. 19 17:21, Robert Hancock wrote: >>> On 2019-06-06 4:09 a.m., Ardelean, Alexandru wrote: >>>> On Wed, 2019-06-05 at 15:07 -0600, Robert Hancock wrote: >>>>> [External] >>>>> >>>>> >>>>> Since the XADC logic can be used with standalone Xilinx FPGAs, this driver >>>>> can potentially be used with various ARM platforms, not just Zynq. >>>>> Change the Zynq dependency to ARM in the list of supported platforms >>>>> in the Kconfig dependencies for this driver. >>>> >>>> To my knowledge, there are 3 FPGA platforms with ARM supported in Linux. >>>> And symbols are ARCH_ZYNQ, ARCH_ZYNQMP & ARCH_SOCFPGA. >>>> For these ARM + FPGA SoCs, it is usually preferred to list the supported/tested ARM + FPGA platforms in Kconfig. >>>> >>>> I am curious: are you using something that isn't in the above list? >>> >>> Yes, we are using the XADC on a Kintex-7 FPGA through a PCIe to AXI >>> bridge using an iMX6D platform - not an integrated ARM+FPGA. >>> > > In that case, it would be a bit more interesting to do a depends on > PCIE_XILINX, or whichever is the Kconfig symbol for the PCIe-to-AXI > bridge. > > And there are some benefits to that, the major being that you can also > support other ARCHs as well (x86, ppc, mips, etc). There isn't a kernel driver for that PCIe-AXI bridge - it doesn't really do much very interesting on its own, it just acts as a regular PCIe endpoint and has build-time settings to map AXI memory to PCIe BARs and host memory into AXI memory space. You have to build your own logic to do things like map interrupts from the AXI side onto MSI interrupts from the bridge. It kind of seems like the easiest solution would be to just delete the platform restriction entirely for this driver, as I really don't see anything platform specific in there. Would anyone object to that? > > Naturally, if using a different PCIe-to-AXI bridge controller (other > than Xilinx's), it would be an idea to use that Kconfig symbol. > >>> Using such an approach this driver could potentially be used on just >>> about any platform, but I didn't want to open it up too much for now in >>> case of some compile issues. >> >> 0day system should answer this for you. >> >> M -- Robert Hancock Senior Software Developer SED Systems, a division of Calian Ltd. Email: hancock@xxxxxxxxxxxxx
