Hi Michal,
On Fri, Oct 26, 2018 at 12:54 AM Michal Simek wrote:
> > Ok, I had suspected you tested it and probably didn't run into issues,
> > but just wanted to make sure we think about it. If you don't mind, swap
> > it around as I suggested just to be safe.
> >
> > With that change feel free
On 23. 10. 18 13:04, Moritz Fischer wrote:
> Hi Mike,
>
> On Tue, Oct 23, 2018 at 10:53:50AM +, Mike Looijmans wrote:
>> On 23-10-18 11:01, Moritz Fischer wrote:
>>> Hi Mike,
>>>
>>> seems like a good usecase (though uncommon), question below
>>
>> Usecases for ICAP:
>> - It's considerably fas
Hi Mike,
On Tue, Oct 23, 2018 at 10:53:50AM +, Mike Looijmans wrote:
> On 23-10-18 11:01, Moritz Fischer wrote:
> > Hi Mike,
> >
> > seems like a good usecase (though uncommon), question below
>
> Usecases for ICAP:
> - It's considerably faster than PCAP
> - Self-repairing logic (e.g. single
On 23-10-18 11:01, Moritz Fischer wrote:
> Hi Mike,
>
> seems like a good usecase (though uncommon), question below
Usecases for ICAP:
- It's considerably faster than PCAP
- Self-repairing logic (e.g. single-event upsets)
- Being programmed from a remote FPGA
- Programming through another bus (e.
Hi Mike,
seems like a good usecase (though uncommon), question below
On Tue, Oct 23, 2018 at 08:31:19AM +0200, Mike Looijmans wrote:
> The Xilinx Zynq FPGA driver takes ownership of the PR interface, making
> it impossible to use the ICAP interface for partial reconfiguration.
>
> This patch cha
The Xilinx Zynq FPGA driver takes ownership of the PR interface, making
it impossible to use the ICAP interface for partial reconfiguration.
This patch changes the driver to only activate PR over PCAP while the
device is actively being accessed by the driver for programming.
This allows both PCAP
6 matches
Mail list logo
