Hi Mauro, On Fri, 31 Dec 2010 09:47:41 -0200, Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxx> 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. > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
