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 [email protected]
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
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
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/[email protected]/msg26422.html
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
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.
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/[email protected]/msg26422.html
--
Regards,
Laurent Pinchart
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/[email protected]/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
On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <[email protected]> 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
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/[email protected]/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
В сообщении от 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/[email protected]/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
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/[email protected]/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
Hi Linus,
On Monday 07 March 2011 17:39:43 Linus Torvalds wrote:
> On Mon, Mar 7, 2011 at 8:16 AM, Greg KH <[email protected]> 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
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.