Re: [U-Boot] [PATCH] fpga: allow programming fpga from FIT image for all FPGA drivers
On 28.11.2017 14:46, Michal Simek wrote:
On 28.11.2017 10:08, Goldschmidt Simon wrote:
Simon Goldschmidt wrote:
Hi Simon,
Simon Glass wrote:
I see that, although it is adding to the fpga header so presumably making it harder for someone to move this over.
Yes, I'm not happy with changing the header and even xilinx C file to add functionality for altera. However, this is due to the fact that a core file still depends on an dogs implementation, which I removed.
This should have meant "on an fpga implementation". No dogs or offences here. My mobile phone does not know the word "fpga", obviously.
Does anyone on cc know the plan fr conversion of FPGA to driver model? It does not look too tricky from a quick look at the header file.
It does not look tricky, indeed. However, we should try to match this to the Linux implementation regarding what's needed in the device tree. And I just don't know that part, yet ;-)
I have not a problem to enable others fpgas to use this functionality. And transition should be done for all these drivers when someone has a time to do it.
Great, thanks! So via which tree would this be included?
Regards, Simon
On 29.11.2017 06:20, Goldschmidt Simon wrote:
On 28.11.2017 14:46, Michal Simek wrote:
On 28.11.2017 10:08, Goldschmidt Simon wrote:
Simon Goldschmidt wrote:
Hi Simon,
Simon Glass wrote:
I see that, although it is adding to the fpga header so presumably making it harder for someone to move this over.
Yes, I'm not happy with changing the header and even xilinx C file to add functionality for altera. However, this is due to the fact that a core file still depends on an dogs implementation, which I removed.
This should have meant "on an fpga implementation". No dogs or offences here. My mobile phone does not know the word "fpga", obviously.
Does anyone on cc know the plan fr conversion of FPGA to driver model? It does not look too tricky from a quick look at the header file.
It does not look tricky, indeed. However, we should try to match this to the Linux implementation regarding what's needed in the device tree. And I just don't know that part, yet ;-)
I have not a problem to enable others fpgas to use this functionality. And transition should be done for all these drivers when someone has a time to do it.
Great, thanks! So via which tree would this be included?
Origin code was applied via my tree. It means it shouldn't be an issue to do that again. Anyway I have tested it on zynqmp and this feature is still working without any issue when this patch is applied.
sjg: Do you see any other issue with this patch?
Thanks, Michal
Hi Michal,
On 29 November 2017 at 03:00, Michal Simek michal.simek@xilinx.com wrote:
On 29.11.2017 06:20, Goldschmidt Simon wrote:
On 28.11.2017 14:46, Michal Simek wrote:
On 28.11.2017 10:08, Goldschmidt Simon wrote:
Simon Goldschmidt wrote:
Hi Simon,
Simon Glass wrote:
I see that, although it is adding to the fpga header so presumably making it harder for someone to move this over.
Yes, I'm not happy with changing the header and even xilinx C file to add functionality for altera. However, this is due to the fact that a core file still depends on an dogs implementation, which I removed.
This should have meant "on an fpga implementation". No dogs or offences here. My mobile phone does not know the word "fpga", obviously.
Does anyone on cc know the plan fr conversion of FPGA to driver model? It does not look too tricky from a quick look at the header file.
It does not look tricky, indeed. However, we should try to match this to the Linux implementation regarding what's needed in the device tree. And I just don't know that part, yet ;-)
I have not a problem to enable others fpgas to use this functionality. And transition should be done for all these drivers when someone has a time to do it.
Great, thanks! So via which tree would this be included?
Origin code was applied via my tree. It means it shouldn't be an issue to do that again. Anyway I have tested it on zynqmp and this feature is still working without any issue when this patch is applied.
sjg: Do you see any other issue with this patch?
No other issues.
Regards Simon
Hi,
On 2.12.2017 04:29, Simon Glass wrote:
Hi Michal,
On 29 November 2017 at 03:00, Michal Simek michal.simek@xilinx.com wrote:
On 29.11.2017 06:20, Goldschmidt Simon wrote:
On 28.11.2017 14:46, Michal Simek wrote:
On 28.11.2017 10:08, Goldschmidt Simon wrote:
Simon Goldschmidt wrote:
Hi Simon,
Simon Glass wrote: > I see that, although it is adding to the fpga header so presumably > making it harder for someone to move this over.
Yes, I'm not happy with changing the header and even xilinx C file to add functionality for altera. However, this is due to the fact that a core file still depends on an dogs implementation, which I removed.
This should have meant "on an fpga implementation". No dogs or offences here. My mobile phone does not know the word "fpga", obviously.
> Does anyone on cc know the plan fr conversion of FPGA to driver model? > It does not look too tricky from a quick look at the header file.
It does not look tricky, indeed. However, we should try to match this to the Linux implementation regarding what's needed in the device tree. And I just don't know that part, yet ;-)
I have not a problem to enable others fpgas to use this functionality. And transition should be done for all these drivers when someone has a time to do it.
Great, thanks! So via which tree would this be included?
Origin code was applied via my tree. It means it shouldn't be an issue to do that again. Anyway I have tested it on zynqmp and this feature is still working without any issue when this patch is applied.
sjg: Do you see any other issue with this patch?
No other issues.
ok. Then applied to my xilinx tree.
Thanks, Michal
participants (3)
-
Goldschmidt Simon -
Michal Simek -
Simon Glass