On Sat, 2019-06-08 at 13:00 +0100, Jonathan Cameron wrote: > [External] > > > 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. Sounds fine to me as well. I guess the initial intent (with ARCH_ depends) was to limit to what was tested, when the driver was written initially. However, other users can try this on their own with different combinations (like the ones mentioned above). Thanks for the info btw: it was informative (I learned something). Thanks Alex > > 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
