Re: [PATCH 01/18] Altera FPGA firmware download module.
Em 07-01-2011 17:31, Ben Gamari escreveu: Hi Mauro, On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: Em 31-12-2010 09:30, Laurent Pinchart escreveu: Hi Mauro, [snip] I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Moving it to userspace would mean a kernel driver that would depend on an userspace daemon^Wfirmware loader to work. I would NAK such designs. The way it is is fine from my POV. Any furthur comment on this? As I noted, I strongly disagree and would point out that there is no shortage of precedent for the use of userspace callbacks for loading of firmware, especially when the process is as tricky as this. I also work with Altera FPGAs and have a strong interest in making this work yet from my perspective it seems pretty clear that the best way forward both for both maintainability and useability is to keep this code in user-space. There is absolutely no reason why this code _must_ be in the kernel and punting it out to userspace only requires a udev rule. Placing this functionality in userspace results in a massive duplication of code, as there are already a number of functional user-space JTAG implementations. On all V4L/DVB drivers I'm ware of, firmwares are loaded via request_firmware, when userspace tries to use the device, or when the driver is loaded (eventually, it might have some v4l/dvb legacy drivers with some weird implementation, but this is a bad practice). There's currently no V4L/DVB load firmware daemon or V4L/DVB udev rules for loading firmware that I'm ware of, and I don't like the idea of adding an extra complexity for userspace to use this device. So, I'll be adding this driver as proposed. Yet, as some points are risen, I'll be moving those drivers to staging for 2.6.38. This will give you some time for propose patches and to better discuss this question. If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. Agreed, but I don't think this would be a good reason to block the code merge for .38. Sure, but there should be agreement that a kernel-mode JTAG state machine really is the best way forward (i.e. necessary for effective firmware upload) before we commit to carry this code around forever. - Ben -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
В сообщении от 5 января 2011 12:26:03 автор Laurent Pinchart написал: Hi, On Friday 31 December 2010 16:04:13 Ben Gamari wrote: On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab wrote: I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Moving it to userspace would mean a kernel driver that would depend on an userspace daemon^Wfirmware loader to work. I would NAK such designs. Why? I agree that JTAG is a lot to place in the kernel and is much better suited to be in user space. What exactly is your objection to depending on a userspace utility? There is no shortage of precedent for loading firmware in userspace (e.g. fx2 usb devices). I agree with this. Mauro, why would a userspace firmware loader be such a bad idea ? If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. Agreed, but I don't think this would be a good reason to block the code merge for .38. I agree with the above isn't good reason to block it but if there is still debate about the general architecture of the code (see above), then it seems aren't ready yet. The code looks very nice, but I'm not at all convinced that it needs to be in the kernel. Just my two-tenths of a cent. We all realize, that FPGA programming not belongs to DVB only, it is more common. But my intention to write driver for DVB and V4L device... Yes, it needed for DVB device to work, and it works on real hardware. FPGA model used in device has not flash memory. So every time the so-called firmware has to be loaded on early device initialization stage. Then FPGA itself drives CI and hardware PID filter. Fhysically, FPGA JTAG interface connected to cx23885 GPIO lines. Take a look on media/dvb/dvb-usb drivers. There is a lot of FX2 firmware dependant devices, but no one of them uses userspace utilities to push firmware inside. If someone has something to put on table, I mean code implementation, then put it on. Everithing is possible to change, but it is needed to begin with something. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
Hi, On Friday 31 December 2010 16:04:13 Ben Gamari wrote: On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab wrote: I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Moving it to userspace would mean a kernel driver that would depend on an userspace daemon^Wfirmware loader to work. I would NAK such designs. Why? I agree that JTAG is a lot to place in the kernel and is much better suited to be in user space. What exactly is your objection to depending on a userspace utility? There is no shortage of precedent for loading firmware in userspace (e.g. fx2 usb devices). I agree with this. Mauro, why would a userspace firmware loader be such a bad idea ? If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. Agreed, but I don't think this would be a good reason to block the code merge for .38. I agree with the above isn't good reason to block it but if there is still debate about the general architecture of the code (see above), then it seems aren't ready yet. The code looks very nice, but I'm not at all convinced that it needs to be in the kernel. Just my two-tenths of a cent. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
В сообщении от 31 декабря 2010 12:53:16 автор Mauro Carvalho Chehab написал: Em 31-12-2010 03:26, Igor M. Liplianin escreveu: It uses STAPL files and programs Altera FPGA through JTAG. Interface to JTAG must be provided from main device module, for example through cx23885 GPIO. Signed-off-by: Igor M. Liplianin liplia...@netup.ru There's something wrong with the way you sent your patches: They were sent with some random dates (most patches are from Aug), so they went out-of-order in patchwork and at the default email display order. Also, patch 4/18 seems missed. Cheers, Mauro Sorry, I'm experimenting with automating to send patches and have such result... Gmail account blocked for a day :( «5.4.5 Daily sending quota exceeded. b52sm12000609eei.19» I will resend with new dates. In addition I will make some fixes Randy Dunlap write about. -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
Em 31-12-2010 03:26, Igor M. Liplianin escreveu: It uses STAPL files and programs Altera FPGA through JTAG. Interface to JTAG must be provided from main device module, for example through cx23885 GPIO. Signed-off-by: Igor M. Liplianin liplia...@netup.ru There's something wrong with the way you sent your patches: They were sent with some random dates (most patches are from Aug), so they went out-of-order in patchwork and at the default email display order. Also, patch 4/18 seems missed. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
Hi Mauro, On Friday 31 December 2010 12:27:38 Mauro Carvalho Chehab wrote: Em 31-12-2010 09:12, Laurent Pinchart escreveu: Hi Igor, On Friday 31 December 2010 06:26:31 Igor M. Liplianin wrote: It uses STAPL files and programs Altera FPGA through JTAG. Interface to JTAG must be provided from main device module, for example through cx23885 GPIO. It might be a bit late for this comment (sorry for not having noticed the patch set earlier), but... Do we really need a complete JTAG implementation in the kernel ? Wouldn't it better to handle this in userspace with a tiny kernel driver to access the JTAG signals ? Laurent, Igor already explained it. From what I understood, the device he is working has a firmware that needs to be loaded via JTAG/FPGA. I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Actually, I liked the idea, as the FPGA programming driver could be useful if other drivers have similar usecases. If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
Em 31-12-2010 09:30, Laurent Pinchart escreveu: Hi Mauro, On Friday 31 December 2010 12:27:38 Mauro Carvalho Chehab wrote: Em 31-12-2010 09:12, Laurent Pinchart escreveu: Hi Igor, On Friday 31 December 2010 06:26:31 Igor M. Liplianin wrote: It uses STAPL files and programs Altera FPGA through JTAG. Interface to JTAG must be provided from main device module, for example through cx23885 GPIO. It might be a bit late for this comment (sorry for not having noticed the patch set earlier), but... Do we really need a complete JTAG implementation in the kernel ? Wouldn't it better to handle this in userspace with a tiny kernel driver to access the JTAG signals ? Laurent, Igor already explained it. From what I understood, the device he is working has a firmware that needs to be loaded via JTAG/FPGA. I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Moving it to userspace would mean a kernel driver that would depend on an userspace daemon^Wfirmware loader to work. I would NAK such designs. The way it is is fine from my POV. Actually, I liked the idea, as the FPGA programming driver could be useful if other drivers have similar usecases. If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. Agreed, but I don't think this would be a good reason to block the code merge for .38. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab mche...@infradead.org wrote: I understand this. However, a complete JTAG state machine in the kernel, plus an Altera firmware parser, seems to be a lot of code that could live in userspace. Moving it to userspace would mean a kernel driver that would depend on an userspace daemon^Wfirmware loader to work. I would NAK such designs. Why? I agree that JTAG is a lot to place in the kernel and is much better suited to be in user space. What exactly is your objection to depending on a userspace utility? There is no shortage of precedent for loading firmware in userspace (e.g. fx2 usb devices). If I understand it correctly the driver assumes the firmware is in an Altera proprietary format. If we really want JTAG code in the kernel we should at least split the file parser and the TAP access code. Agreed, but I don't think this would be a good reason to block the code merge for .38. I agree with the above isn't good reason to block it but if there is still debate about the general architecture of the code (see above), then it seems aren't ready yet. The code looks very nice, but I'm not at all convinced that it needs to be in the kernel. Just my two-tenths of a cent. Cheers, - Ben -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/18] Altera FPGA firmware download module.
On Fri, 31 Dec 2010 08:26:31 +0300 Igor M. Liplianin wrote:
It uses STAPL files and programs Altera FPGA through JTAG.
Interface to JTAG must be provided from main device module,
for example through cx23885 GPIO.
Signed-off-by: Igor M. Liplianin liplia...@netup.ru
---
drivers/misc/Kconfig |1 +
drivers/misc/Makefile|1 +
drivers/misc/altera-stapl/Kconfig|8 +
drivers/misc/altera-stapl/Makefile |3 +
drivers/misc/altera-stapl/altera-comp.c | 142 ++
drivers/misc/altera-stapl/altera-exprt.h | 33 +
drivers/misc/altera-stapl/altera-jtag.c | 1010
drivers/misc/altera-stapl/altera-jtag.h | 113 ++
drivers/misc/altera-stapl/altera-lpt.c | 70 +
drivers/misc/altera-stapl/altera.c | 2484
++
include/misc/altera.h| 49 +
11 files changed, 3914 insertions(+), 0 deletions(-)
create mode 100644 drivers/misc/altera-stapl/Kconfig
create mode 100644 drivers/misc/altera-stapl/Makefile
create mode 100644 drivers/misc/altera-stapl/altera-comp.c
create mode 100644 drivers/misc/altera-stapl/altera-exprt.h
create mode 100644 drivers/misc/altera-stapl/altera-jtag.c
create mode 100644 drivers/misc/altera-stapl/altera-jtag.h
create mode 100644 drivers/misc/altera-stapl/altera-lpt.c
create mode 100644 drivers/misc/altera-stapl/altera.c
create mode 100644 include/misc/altera.h
diff --git a/drivers/misc/altera-stapl/Kconfig
b/drivers/misc/altera-stapl/Kconfig
new file mode 100644
index 000..711a4a2
--- /dev/null
+++ b/drivers/misc/altera-stapl/Kconfig
@@ -0,0 +1,8 @@
+comment Altera FPGA firmware download module
+
+config ALTERA_STAPL
+ tristate Altera FPGA firmware download module
+ depends on I2C
+ default m
+ help
Please do not enable random drivers to build by default.
+static int altera_get_note(u8 *p, s32 program_size,
+ s32 *offset, char *key, char *value, int length)
+/*
+Gets key and value of NOTE fields in the JBC file.
+Can be called in two modes: if offset pointer is NULL,
+then the function searches for note fields which match
+the key string provided. If offset is not NULL, then
+the function finds the next note field of any key,
+starting at the offset specified by the offset pointer.
+Returns 0 for success, else appropriate error code */
+{
/*
* Throughout all source files:
* The multi-line comment format for Linux kernel is like this multi-line
comment.
*/
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
desserts: http://www.xenotime.net/linux/recipes/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
