On Fri, 7 Jun 2019 13:32:11 -0600 Robert Hancock <hancock@xxxxxxxxxxxxx> wrote: > 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? Sounds good to me. Jonathan > > > > > 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 >
