linux-next: manual merge of the staging tree with the v4l-dvb tree

linux-next: manual merge of the staging tree with the v4l-dvb tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the staging tree got a conflict in
drivers/staging/Kconfig between commit
a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
download module") from the v4l-dvb tree and commit
0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
staging driver") from the staging tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/staging/Kconfig
index 1ae0c1b,5295d85..0000000
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@@ -179,7 -177,7 +177,9 @@@ source "drivers/staging/cptm1217/Kconfi
  
  source "drivers/staging/ste_rmi4/Kconfig"
  
 +source "drivers/staging/altera-stapl/Kconfig"
 +
+ source "drivers/staging/gma500/Kconfig"
+ 
  endif # !STAGING_EXCLUDE_BUILD
  endif # STAGING

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the staging tree got a conflict in
> drivers/staging/Kconfig between commit
> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> download module") from the v4l-dvb tree and commit
> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> staging driver") from the staging tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

That looks correct.

Mauro, what is this driver and why is it added to the staging tree?

curious,

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Hi Greg,

Em 04-03-2011 14:13, Greg KH escreveu:
> On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> Today's linux-next merge of the staging tree got a conflict in
>> drivers/staging/Kconfig between commit
>> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
>> download module") from the v4l-dvb tree and commit
>> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
>> staging driver") from the staging tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary.
> 
> That looks correct.
> 
> Mauro, what is this driver and why is it added to the staging tree?

This driver implements the FPGA programming logic for a firmware required
by a DVB driver, and was proposed initially for 2.6.37 inclusion. During the
2.6.38 development cycle, it suffered several revisions, based on our input
at the media and lkml mailing lists, where Igor fixed all CodingStyle issues.

In the last minute, during 2.6.38 merge window, two developers (Laurent and Ben) 
[1] complained against adding a driver for loading FPGA firmware as-is. So, I
decided to add it, for now, at staging, to avoid needing to postpone a long series 
of patches again just because of that, especially since a series of DVB-C devices
are without support on Linux without this patch series, and there are very few
DVB-C devices currently supported.

The Altera driver is compliant with CodingStyle, and, from my side, it is ok
to move it to drivers/others, but it doesn't hurt to give some time for Ben and 
Laurent to propose alternative way of implementing the firmware request logic.

If nothing happens until 2.6.40 merge window, I think we should go forward and
move it to the proper place.

Cheers,
Mauro

[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Greg KH]

On Fri, Mar 04, 2011 at 02:54:24PM -0300, Mauro Carvalho Chehab wrote:
> Hi Greg,
> 
> Em 04-03-2011 14:13, Greg KH escreveu:
> > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> >> Hi Greg,
> >>
> >> Today's linux-next merge of the staging tree got a conflict in
> >> drivers/staging/Kconfig between commit
> >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> >> download module") from the v4l-dvb tree and commit
> >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> >> staging driver") from the staging tree.
> >>
> >> I fixed it up (see below) and can carry the fix as necessary.
> > 
> > That looks correct.
> > 
> > Mauro, what is this driver and why is it added to the staging tree?
> 
> This driver implements the FPGA programming logic for a firmware required
> by a DVB driver, and was proposed initially for 2.6.37 inclusion. During the
> 2.6.38 development cycle, it suffered several revisions, based on our input
> at the media and lkml mailing lists, where Igor fixed all CodingStyle issues.
> 
> In the last minute, during 2.6.38 merge window, two developers (Laurent and Ben) 
> [1] complained against adding a driver for loading FPGA firmware as-is. So, I
> decided to add it, for now, at staging, to avoid needing to postpone a long series 
> of patches again just because of that, especially since a series of DVB-C devices
> are without support on Linux without this patch series, and there are very few
> DVB-C devices currently supported.
> 
> The Altera driver is compliant with CodingStyle, and, from my side, it is ok
> to move it to drivers/others, but it doesn't hurt to give some time for Ben and 
> Laurent to propose alternative way of implementing the firmware request logic.
> 
> If nothing happens until 2.6.40 merge window, I think we should go forward and
> move it to the proper place.

Ok, thanks, I'll defer any patches for this code to you.

greg k-h

Re: linux-next: manual merge of the staging tree with the v4l-dvb tree

[Mauro Carvalho Chehab]

Em 04-03-2011 18:23, Greg KH escreveu:
> On Fri, Mar 04, 2011 at 02:54:24PM -0300, Mauro Carvalho Chehab wrote:
>> Hi Greg,
>>
>> Em 04-03-2011 14:13, Greg KH escreveu:
>>> On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
>>>> Hi Greg,
>>>>
>>>> Today's linux-next merge of the staging tree got a conflict in
>>>> drivers/staging/Kconfig between commit
>>>> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
>>>> download module") from the v4l-dvb tree and commit
>>>> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
>>>> staging driver") from the staging tree.
>>>>
>>>> I fixed it up (see below) and can carry the fix as necessary.
>>>
>>> That looks correct.
>>>
>>> Mauro, what is this driver and why is it added to the staging tree?
>>
>> This driver implements the FPGA programming logic for a firmware required
>> by a DVB driver, and was proposed initially for 2.6.37 inclusion. During the
>> 2.6.38 development cycle, it suffered several revisions, based on our input
>> at the media and lkml mailing lists, where Igor fixed all CodingStyle issues.
>>
>> In the last minute, during 2.6.38 merge window, two developers (Laurent and Ben) 
>> [1] complained against adding a driver for loading FPGA firmware as-is. So, I
>> decided to add it, for now, at staging, to avoid needing to postpone a long series 
>> of patches again just because of that, especially since a series of DVB-C devices
>> are without support on Linux without this patch series, and there are very few
>> DVB-C devices currently supported.
>>
>> The Altera driver is compliant with CodingStyle, and, from my side, it is ok
>> to move it to drivers/others, but it doesn't hurt to give some time for Ben and 
>> Laurent to propose alternative way of implementing the firmware request logic.
>>
>> If nothing happens until 2.6.40 merge window, I think we should go forward and
>> move it to the proper place.
> 
> Ok, thanks, I'll defer any patches for this code to you.

Ok, thanks!
Mauro.

Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> Em 04-03-2011 14:13, Greg KH escreveu:
> > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> >> Today's linux-next merge of the staging tree got a conflict in
> >> drivers/staging/Kconfig between commit
> >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> >> download module") from the v4l-dvb tree and commit
> >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> >> staging driver") from the staging tree.
> >> 
> >> I fixed it up (see below) and can carry the fix as necessary.
> > 
> > That looks correct.
> > 
> > Mauro, what is this driver and why is it added to the staging tree?
> 
> This driver implements the FPGA programming logic for a firmware required
> by a DVB driver, and was proposed initially for 2.6.37 inclusion. During
> the 2.6.38 development cycle, it suffered several revisions, based on our
> input at the media and lkml mailing lists, where Igor fixed all
> CodingStyle issues.
> 
> In the last minute, during 2.6.38 merge window, two developers (Laurent and
> Ben) [1] complained against adding a driver for loading FPGA firmware
> as-is. So, I decided to add it, for now, at staging, to avoid needing to
> postpone a long series of patches again just because of that, especially
> since a series of DVB-C devices are without support on Linux without this
> patch series, and there are very few DVB-C devices currently supported.
> 
> The Altera driver is compliant with CodingStyle, and, from my side, it is
> ok to move it to drivers/others, but it doesn't hurt to give some time for
> Ben and Laurent to propose alternative way of implementing the firmware
> request logic.
> 
> If nothing happens until 2.6.40 merge window, I think we should go forward
> and move it to the proper place.

What's the policy regarding firmware loaders in kernelspace vs. userspace ? 
JTAG is a quite complex protocol, and we already have lots of JTAG libraries 
in userspace (http://urjtag.org/ seems to be the most popular one). We also 
have userspace firmware loaders (such as fxload for the Cypress EZ USB 
microcontrollers). Do we need a kernelspace JTAG implementation ?

> [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Greg KH]

On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > Em 04-03-2011 14:13, Greg KH escreveu:
> > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > >> Today's linux-next merge of the staging tree got a conflict in
> > >> drivers/staging/Kconfig between commit
> > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA firmware
> > >> download module") from the v4l-dvb tree and commit
> > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel GMA500
> > >> staging driver") from the staging tree.
> > >> 
> > >> I fixed it up (see below) and can carry the fix as necessary.
> > > 
> > > That looks correct.
> > > 
> > > Mauro, what is this driver and why is it added to the staging tree?
> > 
> > This driver implements the FPGA programming logic for a firmware required
> > by a DVB driver, and was proposed initially for 2.6.37 inclusion. During
> > the 2.6.38 development cycle, it suffered several revisions, based on our
> > input at the media and lkml mailing lists, where Igor fixed all
> > CodingStyle issues.
> > 
> > In the last minute, during 2.6.38 merge window, two developers (Laurent and
> > Ben) [1] complained against adding a driver for loading FPGA firmware
> > as-is. So, I decided to add it, for now, at staging, to avoid needing to
> > postpone a long series of patches again just because of that, especially
> > since a series of DVB-C devices are without support on Linux without this
> > patch series, and there are very few DVB-C devices currently supported.
> > 
> > The Altera driver is compliant with CodingStyle, and, from my side, it is
> > ok to move it to drivers/others, but it doesn't hurt to give some time for
> > Ben and Laurent to propose alternative way of implementing the firmware
> > request logic.
> > 
> > If nothing happens until 2.6.40 merge window, I think we should go forward
> > and move it to the proper place.
> 
> What's the policy regarding firmware loaders in kernelspace vs. userspace ? 
> JTAG is a quite complex protocol, and we already have lots of JTAG libraries 
> in userspace (http://urjtag.org/ seems to be the most popular one). We also 
> have userspace firmware loaders (such as fxload for the Cypress EZ USB 
> microcontrollers). Do we need a kernelspace JTAG implementation ?
> 
> > [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html

If the code is just a "pass-through" to the hardware, I have no
objection to the driver being in the kernel, if it needs to be in order
to control the hardware properly.

thanks,

greg k-h

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Linus Torvalds]

On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <greg@kroah.com> wrote:
>
> If the code is just a "pass-through" to the hardware, I have no
> objection to the driver being in the kernel, if it needs to be in order
> to control the hardware properly.

.. or even if it doesn't "need to be", and you _could_ do it in user space.

We've had tons of problems with user space breakage and version skew
etc. It's often been a total pain to have user space-vs-kernel
components that support one version but not the other, making it hard
to upgrade the kernel independently of other things. The whole
experience with X-vs-drm has been very painful.

There are two cases where user-space drivers work fine:

 (a) if there is no kernel component to them at all. Think "this
driver would work on not just Linux, but on FreeBSD and UnixWare".
Examples of this would be the original X approach.

 (b) if there's a kernel driver which exports an interface that is
specified by the hardware (NOT specified by some "abstraction" layer),
and where the kernel just exports an interface and doesn't expect
anything back (ie the kernel is _strictly_ the lower-level driver,
there is no two-way "user space helps kernel" crap)

     A reasonable example of this would be the USB user space drivers:
the kernel interface is clearly _below_ (so the kernel does not depend
on user space), and the defined not by some crazy software interface,
but by the USB hardware standard.

But any other kind of mixing is just a big pain. Having a user-space
thing to set things up for a kernel driver is crazy crap. It
inevitably leads to "one or the other is broken, and people working on
one piece aren't the same people working on the other". Just don't do
it. Every time it's done, it leads to problems. You need special
programs to set things up etc. It's just f*cked up.

(An example of why it's crazy crap: it inevitably means that the
kernel can not "resume" a device. Because it now needs user space help
to get the device going again. Crazy. Don't do it. It's shit).

                               Linus

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

Hi Linus,

On Monday 07 March 2011 17:39:43 Linus Torvalds wrote:
> On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <greg@kroah.com> wrote:
> > If the code is just a "pass-through" to the hardware, I have no
> > objection to the driver being in the kernel, if it needs to be in order
> > to control the hardware properly.
> 
> .. or even if it doesn't "need to be", and you _could_ do it in user space.
> 
> We've had tons of problems with user space breakage and version skew
> etc. It's often been a total pain to have user space-vs-kernel
> components that support one version but not the other, making it hard
> to upgrade the kernel independently of other things. The whole
> experience with X-vs-drm has been very painful.
> 
> There are two cases where user-space drivers work fine:
> 
>  (a) if there is no kernel component to them at all. Think "this
> driver would work on not just Linux, but on FreeBSD and UnixWare".
> Examples of this would be the original X approach.
> 
>  (b) if there's a kernel driver which exports an interface that is
> specified by the hardware (NOT specified by some "abstraction" layer),
> and where the kernel just exports an interface and doesn't expect
> anything back (ie the kernel is _strictly_ the lower-level driver,
> there is no two-way "user space helps kernel" crap)
> 
>      A reasonable example of this would be the USB user space drivers:
> the kernel interface is clearly _below_ (so the kernel does not depend
> on user space), and the defined not by some crazy software interface,
> but by the USB hardware standard.
> 
> But any other kind of mixing is just a big pain. Having a user-space
> thing to set things up for a kernel driver is crazy crap. It
> inevitably leads to "one or the other is broken, and people working on
> one piece aren't the same people working on the other". Just don't do
> it. Every time it's done, it leads to problems. You need special
> programs to set things up etc. It's just f*cked up.
> 
> (An example of why it's crazy crap: it inevitably means that the
> kernel can not "resume" a device. Because it now needs user space help
> to get the device going again. Crazy. Don't do it. It's shit).

I agree with you on the pain introduced by mixing drivers with userspace 
helpers. However, I'm still concerned about having a full JTAG stack in the 
kernel.

The Altera JTAG driver is basically a firmware loader. There's nothing wrong 
with firmare loaders in the kernel per-se, we have plenty of them and they 
usually request firmware data from userspace (hopefully specially crafted for 
the Linux driver, or pre-processed when the firmware is extracted from a 
Windows driver) and more of less dump it to the device.

Now, if a vendor provided a firmware in the form of a Java bytecode file, 
requiring the kernel driver to implement a JVM to load the firmware into the 
device, would you accept it ? JTAG is not Java, but it still requires several 
non-trivial layers, from controller drivers (we need to support multiple APIs 
there, as controllers can range from simple bit-banging adapters to more 
complex and faster devices with a higher level interface) to binary firmware 
interpreters (and I'm really talking about intepreters here, not just parsers 
- the Altera firmware file requires a VM) with of course incompatible vendor-
specific formats.

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Olivier Galibert]

On Wed, Mar 09, 2011 at 11:30:59PM +0100, Laurent Pinchart wrote:
> Now, if a vendor provided a firmware in the form of a Java bytecode file, 
> requiring the kernel driver to implement a JVM to load the firmware into the 
> device, would you accept it ?

You extract the data in userspace, turn it into something passive in a
format you define, and implement the actual loader in C in the kernel.
It would not be the first or last time the actual data is extracted
from a vendor-provided package.

  OG.

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

Hi Greg,

On Monday 07 March 2011 17:16:58 Greg KH wrote:
> On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> > On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > > Em 04-03-2011 14:13, Greg KH escreveu:
> > > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > > >> Today's linux-next merge of the staging tree got a conflict in
> > > >> drivers/staging/Kconfig between commit
> > > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA
> > > >> firmware download module") from the v4l-dvb tree and commit
> > > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel
> > > >> GMA500 staging driver") from the staging tree.
> > > >> 
> > > >> I fixed it up (see below) and can carry the fix as necessary.
> > > > 
> > > > That looks correct.
> > > > 
> > > > Mauro, what is this driver and why is it added to the staging tree?
> > > 
> > > This driver implements the FPGA programming logic for a firmware
> > > required by a DVB driver, and was proposed initially for 2.6.37
> > > inclusion. During the 2.6.38 development cycle, it suffered several
> > > revisions, based on our input at the media and lkml mailing lists,
> > > where Igor fixed all CodingStyle issues.
> > > 
> > > In the last minute, during 2.6.38 merge window, two developers (Laurent
> > > and Ben) [1] complained against adding a driver for loading FPGA
> > > firmware as-is. So, I decided to add it, for now, at staging, to avoid
> > > needing to postpone a long series of patches again just because of
> > > that, especially since a series of DVB-C devices are without support
> > > on Linux without this patch series, and there are very few DVB-C
> > > devices currently supported.
> > > 
> > > The Altera driver is compliant with CodingStyle, and, from my side, it
> > > is ok to move it to drivers/others, but it doesn't hurt to give some
> > > time for Ben and Laurent to propose alternative way of implementing
> > > the firmware request logic.
> > > 
> > > If nothing happens until 2.6.40 merge window, I think we should go
> > > forward and move it to the proper place.
> > 
> > What's the policy regarding firmware loaders in kernelspace vs. userspace
> > ? JTAG is a quite complex protocol, and we already have lots of JTAG
> > libraries in userspace (http://urjtag.org/ seems to be the most popular
> > one). We also have userspace firmware loaders (such as fxload for the
> > Cypress EZ USB microcontrollers). Do we need a kernelspace JTAG
> > implementation ?
> > 
> > > [1]
> > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html
> 
> If the code is just a "pass-through" to the hardware, I have no
> objection to the driver being in the kernel, if it needs to be in order
> to control the hardware properly.

The code implements a JTAG TAP state machine with a bit-banging algorithm, 
including direct parallel port (LPT) access, and a bitcode interpreter for the 
files generated by the Altera FPGA proprietary development tools.

-- 
Regards,

Laurent Pinchart

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Igor M. Liplianin]

В сообщении от 7 марта 2011 18:51:27 автор Laurent Pinchart написал:
> Hi Greg,
> 
> On Monday 07 March 2011 17:16:58 Greg KH wrote:
> > On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> > > On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > > > Em 04-03-2011 14:13, Greg KH escreveu:
> > > > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > > > >> Today's linux-next merge of the staging tree got a conflict in
> > > > >> drivers/staging/Kconfig between commit
> > > > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA
> > > > >> firmware download module") from the v4l-dvb tree and commit
> > > > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500: Intel
> > > > >> GMA500 staging driver") from the staging tree.
> > > > >> 
> > > > >> I fixed it up (see below) and can carry the fix as necessary.
> > > > > 
> > > > > That looks correct.
> > > > > 
> > > > > Mauro, what is this driver and why is it added to the staging tree?
> > > > 
> > > > This driver implements the FPGA programming logic for a firmware
> > > > required by a DVB driver, and was proposed initially for 2.6.37
> > > > inclusion. During the 2.6.38 development cycle, it suffered several
> > > > revisions, based on our input at the media and lkml mailing lists,
> > > > where Igor fixed all CodingStyle issues.
> > > > 
> > > > In the last minute, during 2.6.38 merge window, two developers
> > > > (Laurent and Ben) [1] complained against adding a driver for loading
> > > > FPGA firmware as-is. So, I decided to add it, for now, at staging,
> > > > to avoid needing to postpone a long series of patches again just
> > > > because of that, especially since a series of DVB-C devices are
> > > > without support on Linux without this patch series, and there are
> > > > very few DVB-C devices currently supported.
> > > > 
> > > > The Altera driver is compliant with CodingStyle, and, from my side,
> > > > it is ok to move it to drivers/others, but it doesn't hurt to give
> > > > some time for Ben and Laurent to propose alternative way of
> > > > implementing the firmware request logic.
> > > > 
> > > > If nothing happens until 2.6.40 merge window, I think we should go
> > > > forward and move it to the proper place.
> > > 
> > > What's the policy regarding firmware loaders in kernelspace vs.
> > > userspace ? JTAG is a quite complex protocol, and we already have lots
> > > of JTAG libraries in userspace (http://urjtag.org/ seems to be the
> > > most popular one). We also have userspace firmware loaders (such as
> > > fxload for the Cypress EZ USB microcontrollers). Do we need a
> > > kernelspace JTAG implementation ?
> > > 
> > > > [1]
> > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.html
> > 
> > If the code is just a "pass-through" to the hardware, I have no
> > objection to the driver being in the kernel, if it needs to be in order
> > to control the hardware properly.
> 
> The code implements a JTAG TAP state machine with a bit-banging algorithm,
> including direct parallel port (LPT) access, and a bitcode interpreter for
LPT access procedure included for historical reason, on early development stages it was used for 
program FPGA, then we swithed to cx23885 GPIO's. Developer can choose(develop) his own procedure 
for JTAG pins access.

> the files generated by the Altera FPGA proprietary development tools.
So, we used this tools. And the code is from widely opened sources.

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks

Re: Kernelspace firmware loaders (was: linux-next: manual merge of the staging tree with the v4l-dvb tree)

[Laurent Pinchart]

Hi Igor,

On Monday 07 March 2011 18:40:28 Igor M. Liplianin wrote:
> В сообщении от 7 марта 2011 18:51:27 автор Laurent Pinchart написал:
> > On Monday 07 March 2011 17:16:58 Greg KH wrote:
> > > On Mon, Mar 07, 2011 at 03:07:36PM +0100, Laurent Pinchart wrote:
> > > > On Friday 04 March 2011 18:54:24 Mauro Carvalho Chehab wrote:
> > > > > Em 04-03-2011 14:13, Greg KH escreveu:
> > > > > > On Fri, Mar 04, 2011 at 04:39:05PM +1100, Stephen Rothwell wrote:
> > > > > >> Today's linux-next merge of the staging tree got a conflict in
> > > > > >> drivers/staging/Kconfig between commit
> > > > > >> a1256092a1e87511c977a3d0ef96151cda77e5c9 ("[media] Altera FPGA
> > > > > >> firmware download module") from the v4l-dvb tree and commit
> > > > > >> 0867b42113ec4eb8646eb361b15cbcfb741ddf5b ("staging: gma500:
> > > > > >> Intel GMA500 staging driver") from the staging tree.
> > > > > >> 
> > > > > >> I fixed it up (see below) and can carry the fix as necessary.
> > > > > > 
> > > > > > That looks correct.
> > > > > > 
> > > > > > Mauro, what is this driver and why is it added to the staging
> > > > > > tree?
> > > > > 
> > > > > This driver implements the FPGA programming logic for a firmware
> > > > > required by a DVB driver, and was proposed initially for 2.6.37
> > > > > inclusion. During the 2.6.38 development cycle, it suffered several
> > > > > revisions, based on our input at the media and lkml mailing lists,
> > > > > where Igor fixed all CodingStyle issues.
> > > > > 
> > > > > In the last minute, during 2.6.38 merge window, two developers
> > > > > (Laurent and Ben) [1] complained against adding a driver for
> > > > > loading FPGA firmware as-is. So, I decided to add it, for now, at
> > > > > staging, to avoid needing to postpone a long series of patches
> > > > > again just because of that, especially since a series of DVB-C
> > > > > devices are without support on Linux without this patch series,
> > > > > and there are very few DVB-C devices currently supported.
> > > > > 
> > > > > The Altera driver is compliant with CodingStyle, and, from my side,
> > > > > it is ok to move it to drivers/others, but it doesn't hurt to give
> > > > > some time for Ben and Laurent to propose alternative way of
> > > > > implementing the firmware request logic.
> > > > > 
> > > > > If nothing happens until 2.6.40 merge window, I think we should go
> > > > > forward and move it to the proper place.
> > > > 
> > > > What's the policy regarding firmware loaders in kernelspace vs.
> > > > userspace ? JTAG is a quite complex protocol, and we already have
> > > > lots of JTAG libraries in userspace (http://urjtag.org/ seems to be
> > > > the most popular one). We also have userspace firmware loaders (such
> > > > as fxload for the Cypress EZ USB microcontrollers). Do we need a
> > > > kernelspace JTAG implementation ?
> > > > 
> > > > > [1]
> > > > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg26422.ht
> > > > > ml
> > > 
> > > If the code is just a "pass-through" to the hardware, I have no
> > > objection to the driver being in the kernel, if it needs to be in order
> > > to control the hardware properly.
> > 
> > The code implements a JTAG TAP state machine with a bit-banging
> > algorithm, including direct parallel port (LPT) access, and a bitcode
> > interpreter for
> 
> LPT access procedure included for historical reason, on early development
> stages it was used for program FPGA, then we swithed to cx23885 GPIO's.
> Developer can choose(develop) his own procedure for JTAG pins access.

Shouldn't LPT support be removed then ?

> > the files generated by the Altera FPGA proprietary development tools.
> 
> So, we used this tools. And the code is from widely opened sources.

Are we going to add support for all proprietary (and standard ?) FPGA file 
formats, with FPGA programming algorithms from multiple vendors, and TAP 
access support at various levels (not all JTAG interfaces can be controlled at 
the bit-banging level, some use higher level commands) to the kernel ? That 
would be a big amount of complex code, for very little benefit.

You could simplify this by going for a single file format across multiple 
devices from multiple vendors, such as XSVF, but I'm not sure it's a good 
solution either.

-- 
Regards,

Laurent Pinchart