Re: [RFC PATCH] fpga: Introduce new fpga subsystem
On 09/25/2013 08:00 AM, Pavel Machek wrote: > Hi! > The firmware approach is interesting. It might be less flexible compared with my original code (see link to git below) that this is >>> >>> On the other hand... that's the interface world wants, right? To most >>> users, fpga bitstream is just a firmware. >>> >> >> No, not really. >> >> The typical assumption with the firmware interface is that there is >> exactly one possible firmware for each device (possibly modulated by >> driver version, but still.) > > Actually, I have seen counterexample there, too. Wifi card had > different firmware for host and access points mode, probably because > internal RAM could not fit both at same time. And another counter example ... For the Zynq based product I am working on, we encourage the end user to create their own bitstreams to customize their application. So we need an easy way for the user to load a bitstream. cat foo.bin > /dev/xdevcfg works well for us. Then we need to make sure that the interface supports partial reconfiguration. That said, having a sane user api that addresses the various fpga use cases would be a win for use since we would not need to write custom user space code for every platform created in the future. I'd like to see this api work with things like PCI based FPGA cards and discrete fpgas that are not integrated with an arm etc. Phlip > > It is not really different; there's internal logic and you are > programming it to do something. You can program FPGA, CPLD, or > firmware for some embedded CPU. > >> This is blatantly not true for an FPGA in >> the most extreme way possible -- there are an almost infinite number of >> ways one can load an FPGA. > > Well, usually the FPGA has some function on the board (unless you are > using it for compute acceleration), and it also wants just one > version. If you have FPGA-based GSM board, you'll want GSM > firmware. If you have FPGA-based WIFI, you'll want WIFI firmware. If > you load GSM firmware there, it will very likely not work because it > needs different amplifiers etc. > > Heck, you probably _could_ use your WIFI card for cryptographics > operations just by loading different firmware. People just don't do > that. I don't expect that to be too different in the FPGA case... > >> However, I have to question the whole idea of an "FPGA subsystem" -- >> there is an almost infinite number of ways to program an FPGA or FPGA >> programming device (which may even be a commodity flash with a >> microcontroller or CPLD, and may be shared with other devices), and it >> really doesn't make any inherent sense to lump them together. > > Firmware loading methods are also different, yet it makes sense to > have uniform way of loading firmware. This is very similar situation. > > Pavel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On 11/30/2012 09:36 AM, Greg KH wrote: On Fri, Nov 30, 2012 at 05:28:47PM +, Arnd Bergmann wrote: On Wednesday 28 November 2012, Eli Billauer wrote: Xillybus is a general-purpose framework for communication between programmable logic (FPGA) and a host. It provides a simple connection between hardware FIFOs in the FPGA and their respective device files on the host. The user space programming model is like piping data from or to the FPGA. The underlying transport between the host and FPGA is either PCIe or AXI (AMBA bus by ARM). The Xillybus logic (IP core) is configurable in the number of pipes it presents and their nature. The driver autodetects these pipes, making it essentially forward-compatible to future configurations. The benefit of having this driver enabled in the kernel is that hardware vendors may release a new card, knowing that it will work out of the box on any future Linux machine, with the specific configuration defined for the FPGA part. This driver has been available for download for over a year, and has been actively used on a wide variety of kernels versions and configurations. I have a much higher-level comment on this driver: There seem to be a number of parties that are interested in having reprogrammable logic available in Linux and that will want to merge their drivers. I'm aware of these other people that must have some interest (and one person I can't mention here because of NDA): Philip Balister (OpenSDR) Dinh Nguyen (ARM SOCFPGA maintainer) Pavel Machek (SOCFPGA contributor) John Linn (Zynq maintainer) Michal Simek (Zynq maintainer) Ira W. Snyder (Carma driver author) Yes, I know of at least one more device other than the ones listed above that wants this type of functionality as well, so defining it in a standard user/kernel api manner would be very good to do. I'm concerned that a standard driver for FPGA's will be a very difficult problem. The Xillybus driver looks interesting on several levels, however my first concern is depends on a FPGA IP block that is not open source. This is not a bad thing, just a potential obstacle for some people. I've been engaged in design discussions today with my customer. Our target is the Xilinx Zynq hardware. The first pass at a driver focuses on creating the minimal amount of code in the kernel doing most of the logic in user space. So the driver code allocates a large chunk of RAM for the FPGA to read/write to, provides a mmap function so user space can see this RAM, also mmaps in the address space of an AXI slave so the user space can control the logic. This approach has no dependencies on what is loaded into the fpga. This is a very different approach then the Xillybus driver, but should also be useful to a large class of people. Hopefully, we can converge on a set of useful drivers, and not end up with a million drivers all based on custom fpga configuration :) Philip thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On 12/01/2012 08:56 AM, Greg KH wrote: On Fri, Nov 30, 2012 at 07:19:16PM -0800, Philip Balister wrote: On 11/30/2012 09:36 AM, Greg KH wrote: On Fri, Nov 30, 2012 at 05:28:47PM +, Arnd Bergmann wrote: On Wednesday 28 November 2012, Eli Billauer wrote: Xillybus is a general-purpose framework for communication between programmable logic (FPGA) and a host. It provides a simple connection between hardware FIFOs in the FPGA and their respective device files on the host. The user space programming model is like piping data from or to the FPGA. The underlying transport between the host and FPGA is either PCIe or AXI (AMBA bus by ARM). The Xillybus logic (IP core) is configurable in the number of pipes it presents and their nature. The driver autodetects these pipes, making it essentially forward-compatible to future configurations. The benefit of having this driver enabled in the kernel is that hardware vendors may release a new card, knowing that it will work out of the box on any future Linux machine, with the specific configuration defined for the FPGA part. This driver has been available for download for over a year, and has been actively used on a wide variety of kernels versions and configurations. I have a much higher-level comment on this driver: There seem to be a number of parties that are interested in having reprogrammable logic available in Linux and that will want to merge their drivers. I'm aware of these other people that must have some interest (and one person I can't mention here because of NDA): Philip Balister (OpenSDR) Dinh Nguyen (ARM SOCFPGA maintainer) Pavel Machek (SOCFPGA contributor) John Linn (Zynq maintainer) Michal Simek (Zynq maintainer) Ira W. Snyder (Carma driver author) Yes, I know of at least one more device other than the ones listed above that wants this type of functionality as well, so defining it in a standard user/kernel api manner would be very good to do. I'm concerned that a standard driver for FPGA's will be a very difficult problem. The Xillybus driver looks interesting on several levels, however my first concern is depends on a FPGA IP block that is not open source. This is not a bad thing, just a potential obstacle for some people. As long as that doesn't affect the kernel code, I don't see the obstacle here. What am I missing? Nothing. The Xillybus approach is valid. It just depends on their piece of fpga code. If you are not willing to license that, you will need to reverse engineer their fpga code, or sues a different (equally valid) method to communicate with the fpga. Think of their fpga blob as a specific implementation of a network card. Not all network cards expose the same hardware interface. The important thing to realize is that the fpga is user configurable. It is possible to create an infinite number of possible "devices" in it that can use any number of device drivers in Linux. Think of it a a soc, with a large part that the end user can customize with his own IP. In the Xilly case, they have created a custom piece of hardware in the fpga that needs a driver with a specific interface to users space. I've been engaged in design discussions today with my customer. Our target is the Xilinx Zynq hardware. The first pass at a driver focuses on creating the minimal amount of code in the kernel doing most of the logic in user space. So the driver code allocates a large chunk of RAM for the FPGA to read/write to, provides a mmap function so user space can see this RAM, also mmaps in the address space of an AXI slave so the user space can control the logic. This approach has no dependencies on what is loaded into the fpga. Would a simple UIO driver work best for this type of arrangement? Then those types of hardware wouldn't even need to mess with a fpga-type interface. It is very close to a UIO approach. My key problem I am trying to solve is getting a "large" buffer space for the driver and a way to communicate the physical address and size of the buffer to the fpga. The fpga has several ports that allow it to directly read/write RAM, but it needs to know physical addresses. This is a very different approach then the Xillybus driver, but should also be useful to a large class of people. Hopefully, we can converge on a set of useful drivers, and not end up with a million drivers all based on custom fpga configuration :) Odds are, this should look something like the firmware interface in the end, right? Userspace dumps a bunch of data to the device, and then needs the driver to toggle some bits somewhere to enable the device. Also, a few control calls like clearing the device, and other minor things should be all that is needed, right? For zynq, there is an out of tree ( :) ) driver that handles the firmware loading. This is an independent problem. So, in the grand tradition of, "The first one there wins", why not
Re: [PATCH 2/2] New driver: Xillybus generic interface for FPGA (programmable logic)
On 12/01/2012 12:48 PM, Arnd Bergmann wrote: On Saturday 01 December 2012, Philip Balister wrote: On 11/30/2012 09:36 AM, Greg KH wrote: Yes, I know of at least one more device other than the ones listed above that wants this type of functionality as well, so defining it in a standard user/kernel api manner would be very good to do. I'm concerned that a standard driver for FPGA's will be a very difficult problem. The Xillybus driver looks interesting on several levels, however my first concern is depends on a FPGA IP block that is not open source. This is not a bad thing, just a potential obstacle for some people. I agree that is a concern, but for now, I'm mostly worried about the kernel-to-user interface. If we can agree on a driver interface that works for Xillybus as well as any of the others we know about, we can start using that as the generic kernel FPGA interface. Once we get a second FPGA driver, that can use the same user interface but talk to the hardware in a different way, and then we can reorganise the code to keep the user interface bits in a common driver, away from the hardware specific parts. Actually, the user interface will depend on what "code" is loaded into the FPGA (side note, people argue over FPGA's being hardware or software). So it is entirely possible to load an FPGA with a XillyBus device, and ethernet interface, I2S, and the "UIO" appraoch I am working on. We can use device tree to tell the kernel what drivers are needed, and Josh mentioned some ideas on managing device tree entries combined with the fpga image. So it is very possible for one fpga to have several device drivers, each using different user interfaces. It is entirely possible to create a device in the fpga that uses an existing hardware interface so you could use the existing Linux driver to control it. If you see anything in the user interface that directly depends on the Xillybus IP block, then that would make the approach impossible and we should change that to be more generic. I've been engaged in design discussions today with my customer. Our target is the Xilinx Zynq hardware. The first pass at a driver focuses on creating the minimal amount of code in the kernel doing most of the logic in user space. So the driver code allocates a large chunk of RAM for the FPGA to read/write to, provides a mmap function so user space can see this RAM, also mmaps in the address space of an AXI slave so the user space can control the logic. This approach has no dependencies on what is loaded into the fpga. This is a very different approach then the Xillybus driver, but should also be useful to a large class of people. Hopefully, we can converge on a set of useful drivers, and not end up with a million drivers all based on custom fpga configuration :) Agreed. If I understand you correctly though, your approach is specific to a particular hardware implementation (Zynq) on the user interface layer, which I think is exactly what we should avoid. Obviously, there is always a driver involved that is specific to the IP block you load into an FPGA at runtime, and that is ok. The two parts that I think we should agree on are: The approach I am taking is not Zynq specific. The only Zynq specific bits will be range checking data from the device tree to make sure the user is mapping address space that is used by the FPGA and a similar validation of the IRQ numbers. I have not looked at the Altera part closely, but I suspect their fpga/processor interface may use similar concepts. a) How to get a payload into the FPGA Just to be clear, what are you calling payload here? Is it the data that is used to configure the fpga, or actual data going back and forth? I'm a little concerned that not everyone understand how flexible the FPGA is. Philip b) How to find a device driver that can make the payload interface to user space. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC] clk: Introduce userspace clock driver
On 05/14/2013 12:46 PM, Mike Turquette wrote: Quoting Sören Brinkmann (2013-05-13 10:58:49) On Mon, May 13, 2013 at 07:37:23PM +0200, Sebastian Hesselbarth wrote: On 05/13/13 19:24, Sören Brinkmann wrote: On Mon, May 13, 2013 at 06:21:13PM +0200, Sebastian Hesselbarth wrote: Well, that driver actually exists. But that just programs a bitstream you give it to program. It does not know anything about the design it programs and cannot make any kind of decision whether the clocks should be userspace controlled or not. what Mark wants to point out is that you add fabric clocks to the Xilinx driver instead. This way, you will have user-space controllable clocks but only if you loaded the xilinx driver first. What "Xilinx driver", are we talking about? The device config driver you mention below. IIRC the fabric clock controller provided by Zynq _is_ always there and accessible from ARM CPUs. You just don't have a new generic driver allowing to poke with all clocks, but a xilinx only driver allowing you to set the (xilinx only) fabric clocks. Right. I've played with Zynq a while ago, did Xilinx mainline the bitfile driver already? If not, why don't you give it a shot? The device config driver is not in mainline, AFAIK. And I think it's in rather bad shape and needs a lot of work before it is upstreamable. But this is probably the right place to put this. It is, as it will only expose clocks on Zynq and that's what Mark and Mike are worried about. Expose clocks to user space and you will have people mess with it for sure. Well, even if you contain it in that driver you can still mess with other clocks. Just give it the "wrong" input clock references in DT and you are free to control them. As I said before, there is no protection against such misuse. My objections are not about creating the most secure platform ever. My objections are about lowering the barrier of entry for folks to misuse the clk api. Clearly anyone that can compile a kernel and flash it to a device can misuse anything they want. Likewise if someone can compile a DTB and flash it then there is another vector for misuse. However, making an api available to any userspace application substantially lowers the barrier to misuse. Physical access to the device is no longer needed in case of flashing new stuff to nand, or emmc or whatever. And by misuse I do not only mean people trying to steal your credit card (I would be impressed if controlling clocks was a part of that!), but I do not want to encourage vendors to implement crap userspace drivers to control clocks instead of upstreaming proper Linux device drivers. And it is clearly possible to destroy a device with irresponsible clock control. While most of us agree that exposing clock controls to userspace is useful for debugging, at this point I do not think the positive aspects of mainlining the feature are strong enough to overcome the negative aspects. I'm sure implementations of this functionality will exist out-of-tree (as pointed out by Peter), but not everything should be merged to mainline. I'm skimming this thread and am concerned there is a level of misunderstanding by many people how Zynq works :) First of all, the driver that loads the bitstream into the fpga fabric does not know ANYTHING about what the bitstream does. So it cannot do any setup based on the contents of the file that is loaded. (And this can also be loaded during the SoC bootup, bypassing this driver completely) Second, there are four clocks that feed the FPGA fabric. We will want to set these clocks from user space somehow. It is perfectly valid to use a uio driver to interface with logic in the fpga. If we take the approach of using such general purpose techniques to interface with fpga logic, we must have ways for the user to control the fpga clocks. I give the Xilinx guys a lot of crap for not upstreaming their drivers fast enough for me :), so I feel obligated to help explain why users want to do this and I do not want to carry out of tree code that is critical to using these devices effectively. I imagine the Altera soc-fpga parts will have similar issues. I suppose I should read the TRM for them one day. Philip Regards, Mike About the shape of it, I didn't expect that to change at all. Just wondering, if it still requires you to manually end it's endianess mess with the bitfiles. If you go at it, consider reading the magic hidden in the bitfile and swap it when it is required. But that will go OT here. It still takes byteswapped, binary images as input, unfortunately. On the other hand, currently this driver is only required for programming the FPGA from Linux, which is not required. One of the bootloaders could do this for you earlier. Well, exposing clocks to user space is not required _at all_ on all other platforms you can think of. So, if you have a Zynq, you can always load a Zynq driver even if you are not going to use it's bitfile programm
Re: [PATCH RFC] clk: Introduce userspace clock driver
On 05/16/2013 12:28 AM, Saravana Kannan wrote: > On 05/14/2013 09:46 PM, Mark Brown wrote: >> On Tue, May 14, 2013 at 02:09:47PM -0400, Philip Balister wrote: >> >>> First of all, the driver that loads the bitstream into the fpga >>> fabric does not know ANYTHING about what the bitstream does. So it >>> cannot do any setup based on the contents of the file that is >>> loaded. (And this can also be loaded during the SoC bootup, >>> bypassing this driver completely) >> >> This is a problem that is going to need to be fixed - there will be some >> things going on the FPGAs that do need drivers and so there needs to be >> some way to instantiate a driver for a FPGA image. Things like adding >> extra DT blobs along with the FPGA image have been talked about >> >>> Second, there are four clocks that feed the FPGA fabric. We will >>> want to set these clocks from user space somehow. It is perfectly >>> valid to use a uio driver to interface with logic in the fpga. If we >>> take the approach of using such general purpose techniques to >>> interface with fpga logic, we must have ways for the user to control >>> the fpga clocks. >> >> Right, and if the specific device is being controlled by UIO then having >> UIO create some clocks makes sense but then that should be integrated >> into the UIO instantiation rather than done as a separate thing. > > Agreed. I was about to reply with exactly the same point. I haven't done > any UIO coding, but that device file will eventually have to be opened. > Turn on the clocks in the open and turn them off at close. > > Rate to request can be a DT property. But you are assuming each device implemented in the fpga uses one clock. This assumption is clearly not valid since devices will ahve to share clocks. Philip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
On 01/16/2014 12:53 PM, Srikanth Thokala wrote:
This is the driver for the AXI Video Direct Memory Access (AXI
VDMA) core, which is a soft Xilinx IP core that provides high-
bandwidth direct memory access between memory and AXI4-Stream
type video target peripherals. The core provides efficient two
dimensional DMA operations with independent asynchronous read
and write channel operation.
[snip]
+/**
+ * xilinx_vdma_start - Start VDMA channel
+ * @chan: Driver specific VDMA channel
+ */
+static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
+{
+ int loop = XILINX_VDMA_LOOP_COUNT + 1;
+
+ vdma_ctrl_set(chan, XILINX_VDMA_REG_DMACR, XILINX_VDMA_DMACR_RUNSTOP);
+
+ /* Wait for the hardware to start */
+ while (loop)
loop-- ?
Philip
+ if (!(vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR) &
+ XILINX_VDMA_DMASR_HALTED))
+ break;
+
+ if (!loop) {
+ dev_err(chan->dev, "Cannot start channel %p: %x\n",
+ chan, vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR));
+
+ chan->err = true;
+ }
+
+ return;
+}
+
+/**
+ * xilinx_vdma_start_transfer - Starts VDMA transfer
+ * @chan: Driver specific channel struct pointer
+ */
+static void xilinx_vdma_start_transfer(struct xilinx_vdma_chan *chan)
+{
+ struct xilinx_vdma_config *config = &chan->config;
+ struct xilinx_vdma_tx_descriptor *desc;
+ unsigned long flags;
+ u32 reg;
+ struct xilinx_vdma_tx_segment *head, *tail = NULL;
+
+ if (chan->err)
+ return;
+
+ spin_lock_irqsave(&chan->lock, flags);
+
+ /* There's already an active descriptor, bail out. */
+ if (chan->active_desc)
+ goto out_unlock;
+
+ if (list_empty(&chan->pending_list))
+ goto out_unlock;
+
+ desc = list_first_entry(&chan->pending_list,
+ struct xilinx_vdma_tx_descriptor, node);
+
+ /* If it is SG mode and hardware is busy, cannot submit */
+ if (chan->has_sg && xilinx_vdma_is_running(chan) &&
+ !xilinx_vdma_is_idle(chan)) {
+ dev_dbg(chan->dev, "DMA controller still busy\n");
+ goto out_unlock;
+ }
+
+ if (chan->err)
+ goto out_unlock;
+
+ /*
+* If hardware is idle, then all descriptors on the running lists are
+* done, start new transfers
+*/
+ if (chan->has_sg) {
+ head = list_first_entry(&desc->segments,
+ struct xilinx_vdma_tx_segment, node);
+ tail = list_entry(desc->segments.prev,
+ struct xilinx_vdma_tx_segment, node);
+
+ vdma_ctrl_write(chan, XILINX_VDMA_REG_CURDESC, head->phys);
+ }
+
+ /* Configure the hardware using info in the config structure */
+ reg = vdma_ctrl_read(chan, XILINX_VDMA_REG_DMACR);
+
+ if (config->frm_cnt_en)
+ reg |= XILINX_VDMA_DMACR_FRAMECNT_EN;
+ else
+ reg &= ~XILINX_VDMA_DMACR_FRAMECNT_EN;
+
+ /*
+* With SG, start with circular mode, so that BDs can be fetched.
+* In direct register mode, if not parking, enable circular mode
+*/
+ if (chan->has_sg || !config->park)
+ reg |= XILINX_VDMA_DMACR_CIRC_EN;
+
+ if (config->park)
+ reg &= ~XILINX_VDMA_DMACR_CIRC_EN;
+
+ vdma_ctrl_write(chan, XILINX_VDMA_REG_DMACR, reg);
+
+ if (config->park && (config->park_frm >= 0) &&
+ (config->park_frm < chan->num_frms)) {
+ if (chan->direction == DMA_MEM_TO_DEV)
+ vdma_write(chan, XILINX_VDMA_REG_PARK_PTR,
+ config->park_frm <<
+ XILINX_VDMA_PARK_PTR_RD_REF_SHIFT);
+ else
+ vdma_write(chan, XILINX_VDMA_REG_PARK_PTR,
+ config->park_frm <<
+ XILINX_VDMA_PARK_PTR_WR_REF_SHIFT);
+ }
+
+ /* Start the hardware */
+ xilinx_vdma_start(chan);
+
+ if (chan->err)
+ goto out_unlock;
+
+ /* Start the transfer */
+ if (chan->has_sg) {
+ vdma_ctrl_write(chan, XILINX_VDMA_REG_TAILDESC, tail->phys);
+ } else {
+ struct xilinx_vdma_tx_segment *segment;
+ int i = 0;
+
+ list_for_each_entry(segment, &desc->segments, node)
+ vdma_desc_write(chan,
+ XILINX_VDMA_REG_START_ADDRESS(i++),
+ segment->hw.buf_addr);
+
+ vdma_desc_write(chan, XILINX_VDMA_REG_HSIZE, config->hsize);
+ vdma_desc_write(chan, XILINX_VDMA_REG_FRMDLY_STRIDE,
+ (config->frm_dly <<
+
Re: [RFC PATCH v1] fpga manager framework with configfs interface
On 06/25/2014 11:43 AM, H. Peter Anvin wrote: > On 06/25/2014 11:37 AM, Alan Tull wrote: >> >> Yes, that's why I've recently felt more love for the firmware >> interface. Since I need resume, it gives me a straightforward path to >> be able to reprogram the FPGA without holding ram for the bitfile. >> Also it is scalable. >> > > The firmware interface is definitely pretty much ideal for the > "production driver" use case... after all, the fact that the firmware > happens to be an FPGA is to some degree an implementation detail (well, > modulo fun things like showing up on the bus with one device ID and then > disconnecting and reconnecting with another device ID after firmware load.) > > There are *so* many use cases for FPGA bitstreams... Agreed! Philip > > -hpa > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
On 09/26/2017 01:50 PM, Moritz Fischer wrote: > Michal, > > On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote: >> Hi, >> >> On 25.9.2017 18:11, Moritz Fischer wrote: >>> Hi Michal, >>> >>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote: >>>> Hi Moritz >>>> >>>> sorry for delay. >>> >>> No problem. >>> >>>> >>>> On 12.9.2017 01:22, Moritz Fischer wrote: >>>>> Add support for the National Instruments Project Sulfur SDR >>>>> motherboards Rev 2,3 and 4. >>>>> >>>>> Signed-off-by: Moritz Fischer >>>>> --- >>>>> arch/arm/boot/dts/Makefile| 3 + >>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts | 84 +++ >>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 >>>>> ++ >>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts | 26 ++ >>>>> arch/arm/boot/dts/zynq-ni-sulfur.dtsi | 133 >>>>> ++ >>>>> 5 files changed, 364 insertions(+) >>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts >>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts >>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts >>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi >>>> >>>> Is this publicly available board? >>> >>> Will be in Q1 2018 was announced at GRCon'17 ([1]). >>> Some of the Rev3s are currently deployed in Norway as part of a radar >>> system. >>> >>>> I am not quite sure we should apply these dts files. There are a lot of >>>> boards with zynq and there must be any strong argument for applying this >>>> to the tree. For arm32 with even flat tree structure. >>> >>> What's the issue with merging them, except for having 3 more files? >> >> For me this is not a problem because on Linux side it is not increasing >> build time. >> I want to see the value for community. All xilinx platforms are >> evaluation generic purpose boards which are showing how to connect stuff >> together. >> On the other hand this is real product. > > Uh. > >> I would let arm-soc maintainer to decide if this is fine or not. I >> definitely don't want to end up in situation that we will have dts for >> real products which are not bringing any value for others. > > Sure, it's the maintainers call. > > I do intend to have my customers run mainline on it eventually, currently > I'm a handful of patches away from making that happen. So yes, running > mainline is a usecase that matters to me. > > It is one thing to keep bitching about vendor kernels as a community > continuously, but then if someone goes through the effort and actually > tries to run mainline, you give them crap like that above. > > Our products usually come with full schematics [1], firmware, fpga code and > all > available, I don't know what makes them less useful to the community as a > platform to experiment and develop on than Xilinx eval boards. > > There's several people that I know of both hobbyists and companies that > build systems around these platforms, so I don't know ... I expect this product to be delivered with full source and a mainline kernel, so lets make it easy for Moritz to do the right thing here. This makes long term support of this product much easier. Acked-by: Philip Balister Philip > > - Moritz > > [1] http://files.ettus.com/schematics/ > signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
On 09/26/2017 02:06 PM, Michal Simek wrote: > On 26.9.2017 19:58, Philip Balister wrote: >> On 09/26/2017 01:50 PM, Moritz Fischer wrote: >>> Michal, >>> >>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote: >>>> Hi, >>>> >>>> On 25.9.2017 18:11, Moritz Fischer wrote: >>>>> Hi Michal, >>>>> >>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote: >>>>>> Hi Moritz >>>>>> >>>>>> sorry for delay. >>>>> >>>>> No problem. >>>>> >>>>>> >>>>>> On 12.9.2017 01:22, Moritz Fischer wrote: >>>>>>> Add support for the National Instruments Project Sulfur SDR >>>>>>> motherboards Rev 2,3 and 4. >>>>>>> >>>>>>> Signed-off-by: Moritz Fischer >>>>>>> --- >>>>>>> arch/arm/boot/dts/Makefile| 3 + >>>>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts | 84 +++ >>>>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 >>>>>>> ++ >>>>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts | 26 ++ >>>>>>> arch/arm/boot/dts/zynq-ni-sulfur.dtsi | 133 >>>>>>> ++ >>>>>>> 5 files changed, 364 insertions(+) >>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts >>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts >>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts >>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi >>>>>> >>>>>> Is this publicly available board? >>>>> >>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]). >>>>> Some of the Rev3s are currently deployed in Norway as part of a radar >>>>> system. >>>>> >>>>>> I am not quite sure we should apply these dts files. There are a lot of >>>>>> boards with zynq and there must be any strong argument for applying this >>>>>> to the tree. For arm32 with even flat tree structure. >>>>> >>>>> What's the issue with merging them, except for having 3 more files? >>>> >>>> For me this is not a problem because on Linux side it is not increasing >>>> build time. >>>> I want to see the value for community. All xilinx platforms are >>>> evaluation generic purpose boards which are showing how to connect stuff >>>> together. >>>> On the other hand this is real product. >>> >>> Uh. >>> >>>> I would let arm-soc maintainer to decide if this is fine or not. I >>>> definitely don't want to end up in situation that we will have dts for >>>> real products which are not bringing any value for others. >>> >>> Sure, it's the maintainers call. >>> >>> I do intend to have my customers run mainline on it eventually, currently >>> I'm a handful of patches away from making that happen. So yes, running >>> mainline is a usecase that matters to me. >>> >>> It is one thing to keep bitching about vendor kernels as a community >>> continuously, but then if someone goes through the effort and actually >>> tries to run mainline, you give them crap like that above. >>> >>> Our products usually come with full schematics [1], firmware, fpga code and >>> all >>> available, I don't know what makes them less useful to the community as a >>> platform to experiment and develop on than Xilinx eval boards. >>> >>> There's several people that I know of both hobbyists and companies that >>> build systems around these platforms, so I don't know ... >> >> I expect this product to be delivered with full source and a mainline >> kernel, so lets make it easy for Moritz to do the right thing here. This >> makes long term support of this product much easier. >> >> Acked-by: Philip Balister > > I think this is the right way to go. Get ACK from Arnd or Olof or Kevin > and I will merge this. > I am simply just afraid that if a lot of zynq customers will ask for it > we can will end up with a lot of zynq/zynqmp based dts files in the > kernel and arm-soc guys will stop this that it is simply too much and > won't accept +1 case. I share the same concerns. Unfortunately, there doesn't seem like any other structured way to manage dts files. As an OpenEmbedded guy, I know I can carry them with BSP's, but not everyone uses OpenEmbedded. I'd love to see a long term scalable solution for tracking dts files, but that is outside the scope of Moritz's request. Philip > > Thanks, > Michal >
Re: [PATCH 1/2] arm: dts: Add support for National Instruments Project Sulfur SDRs
On 10/06/2017 04:49 AM, Michal Simek wrote: > On 26.9.2017 20:15, Philip Balister wrote: >> On 09/26/2017 02:06 PM, Michal Simek wrote: >>> On 26.9.2017 19:58, Philip Balister wrote: >>>> On 09/26/2017 01:50 PM, Moritz Fischer wrote: >>>>> Michal, >>>>> >>>>> On Tue, Sep 26, 2017 at 02:54:48PM +0200, Michal Simek wrote: >>>>>> Hi, >>>>>> >>>>>> On 25.9.2017 18:11, Moritz Fischer wrote: >>>>>>> Hi Michal, >>>>>>> >>>>>>> On Mon, Sep 25, 2017 at 10:19:44AM +0200, Michal Simek wrote: >>>>>>>> Hi Moritz >>>>>>>> >>>>>>>> sorry for delay. >>>>>>> >>>>>>> No problem. >>>>>>> >>>>>>>> >>>>>>>> On 12.9.2017 01:22, Moritz Fischer wrote: >>>>>>>>> Add support for the National Instruments Project Sulfur SDR >>>>>>>>> motherboards Rev 2,3 and 4. >>>>>>>>> >>>>>>>>> Signed-off-by: Moritz Fischer >>>>>>>>> --- >>>>>>>>> arch/arm/boot/dts/Makefile| 3 + >>>>>>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts | 84 +++ >>>>>>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts | 118 >>>>>>>>> ++ >>>>>>>>> arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts | 26 ++ >>>>>>>>> arch/arm/boot/dts/zynq-ni-sulfur.dtsi | 133 >>>>>>>>> ++ >>>>>>>>> 5 files changed, 364 insertions(+) >>>>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev2.dts >>>>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev3.dts >>>>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur-rev4.dts >>>>>>>>> create mode 100644 arch/arm/boot/dts/zynq-ni-sulfur.dtsi >>>>>>>> >>>>>>>> Is this publicly available board? >>>>>>> >>>>>>> Will be in Q1 2018 was announced at GRCon'17 ([1]). >>>>>>> Some of the Rev3s are currently deployed in Norway as part of a radar >>>>>>> system. >>>>>>> >>>>>>>> I am not quite sure we should apply these dts files. There are a lot of >>>>>>>> boards with zynq and there must be any strong argument for applying >>>>>>>> this >>>>>>>> to the tree. For arm32 with even flat tree structure. >>>>>>> >>>>>>> What's the issue with merging them, except for having 3 more files? >>>>>> >>>>>> For me this is not a problem because on Linux side it is not increasing >>>>>> build time. >>>>>> I want to see the value for community. All xilinx platforms are >>>>>> evaluation generic purpose boards which are showing how to connect stuff >>>>>> together. >>>>>> On the other hand this is real product. >>>>> >>>>> Uh. >>>>> >>>>>> I would let arm-soc maintainer to decide if this is fine or not. I >>>>>> definitely don't want to end up in situation that we will have dts for >>>>>> real products which are not bringing any value for others. >>>>> >>>>> Sure, it's the maintainers call. >>>>> >>>>> I do intend to have my customers run mainline on it eventually, currently >>>>> I'm a handful of patches away from making that happen. So yes, running >>>>> mainline is a usecase that matters to me. >>>>> >>>>> It is one thing to keep bitching about vendor kernels as a community >>>>> continuously, but then if someone goes through the effort and actually >>>>> tries to run mainline, you give them crap like that above. >>>>> >>>>> Our products usually come with full schematics [1], firmware, fpga code >>>>> and all >>>>> available, I don't know what makes them less useful to the community as a >>>>> platform to experiment and develop on than Xilinx eval boards. >>>>> >>>>> There's several people that I know of both hobbyists and companies that >>>>> build systems around these platforms, so I don't know ... >>>> >>>> I expect this product to be delivered with full source and a mainline >>>> kernel, so lets make it easy for Moritz to do the right thing here. This >>>> makes long term support of this product much easier. >>>> >>>> Acked-by: Philip Balister >>> >>> I think this is the right way to go. Get ACK from Arnd or Olof or Kevin >>> and I will merge this. >>> I am simply just afraid that if a lot of zynq customers will ask for it >>> we can will end up with a lot of zynq/zynqmp based dts files in the >>> kernel and arm-soc guys will stop this that it is simply too much and >>> won't accept +1 case. >> >> I share the same concerns. Unfortunately, there doesn't seem like any >> other structured way to manage dts files. >> >> As an OpenEmbedded guy, I know I can carry them with BSP's, but not >> everyone uses OpenEmbedded. I'd love to see a long term scalable >> solution for tracking dts files, but that is outside the scope of >> Moritz's request. > > Are you guys coming to ELCE? There will be Devicetree Workshop which > will be good place to talk about this. Yes. When is the workshop? Philip > > Thanks, > Michal >
