Messages in this thread | | | Date | Tue, 27 Jun 2017 10:38:44 -0700 (PDT) | From | matthew.gerlach@linux ... | Subject | Re: [PATCH 3/3] mtd: spi-nor: Altera Quadspi Flash Controller v2 Platform driver |
| |
On Tue, 27 Jun 2017, Marek Vasut wrote:
> On 06/27/2017 05:15 PM, matthew.gerlach@linux.intel.com wrote: >> >> >> On Tue, 27 Jun 2017, Marek Vasut wrote: >> >>> On 06/26/2017 06:13 PM, matthew.gerlach@linux.intel.com wrote: >>>> From: Matthew Gerlach <matthew.gerlach@linux.intel.com> >>> >>> Just wrap it into the Altera QSPI driver , no need for separate platform >>> driver IMO. >> >> Hi Marek, >> >> I answered this question when you asked why the header file was >> necessary, but I think further discussion could be helpful, since this >> problem is becoming more prevelent. The Altera Quadspi component is a >> soft IP in a >> FPGA, and the processor using the component may or may not have device >> tree support compiled into the Linux kernel. Since device tree support >> may or may not be available, the device tree specific code must be >> separated >> from the core driver code. > > I see, that's fine, although there is no PCIe or other support in this > submission. Is that planned ?
You probably would not see a PCIe driver for a card with a FPGA that would only have the Altera Quadspi component on it. Usually a FPGA has several components, each requiring their own driver which are considered sub-drivers of the PCIe driver. I will be adding Altera Quadspi support to the Intel-FPGA PCIe driver that is currently under review. We have also seen people use the Altera Quadspi with a NIOS-II soft processor, and I expect someone would want to use the component with ARM SOCFPGAs.
Matthew Gerlach
> >> One can certainly make the case, that device tree support could/should >> be available everywhere, but the current reality is most x86 Linux >> kernel configurations do not include device tree support. >> >> For the record, I believe device trees, and more specifically device >> tree overlays, are the best way for Linux to use FPGAs, but I have to >> deal with the current realities. >> >> Thanks again for all the great feedback. >> >> Matthew Gerlach > > [...] > > -- > Best regards, > Marek Vasut >
| |