Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

enable drivers/staging/comedi (data acquisition) #534

Closed
berndporr opened this issue Feb 14, 2014 · 8 comments
Closed

enable drivers/staging/comedi (data acquisition) #534

berndporr opened this issue Feb 14, 2014 · 8 comments

Comments

@berndporr
Copy link
Contributor

comedi is a data acquisition framework which allows easy driver development for anything that is analogue and digital IO. This would be very useful to have this enabled in the kernel. I'm developer of the USBDUX boards and I use the raspberry PI in conjunction with these boards:
http://www.linux-usb-daq.co.uk/software2/rpi/
However in order to use the boards I need to re-compile the kernel. I've also developed a small add on card for the RPI which could serve as an example how to write drivers for this framework:
http://web.eng.gla.ac.uk/rpi/
@bigguiness
Copy link
Contributor

On Friday, February 14, 2014 12:32 PM, Bernd Porr wrote:

comedi is a data acquisition framework which allows easy driver
development for anything that is analogue and digital IO. This
would be very useful to have this enabled in the kernel. I'm
developer of the USBDUX boards and I use the raspberry PI
in conjunction with these boards:
http://www.linux-usb-daq.co.uk/software2/rpi/
However in order to use the boards I need to re-compile the
kernel. I've also developed a small add on card for the RPI
which could serve as an example how to write drivers for
this framework:
http://web.eng.gla.ac.uk/rpi/

Hello Bernd,

Do you have any of the add-on cards for the RPI? I would love
to have one to test with comedi.

BTW, I would also love to have one of the USBDUX boards to
test with. :-)

Are you planning on submitting a driver for this board?

Regards,
Hartley

@popcornmix
Copy link
Collaborator

Are you requesting additional module(s) are enabled in bcmrpi_defconfig? If so which one(s)?

@berndporr
Copy link
Contributor Author

Hi Hartley,

I can send you the newest version of the add on card. We will be using
it for teaching in two weeks. I haven't managed to write a driver for
comedi yet but if you have time to write one with me that would be grand.

I'm sure I have a USBDUX-D kicking about. PM me with your postal
address: mail@berndporr.me.uk

/Bernd
P.S.: will send the kernel config to enable comedi later here on GIT.

H Hartley Sweeten wrote:

On Friday, February 14, 2014 12:32 PM, Bernd Porr wrote:

comedi is a data acquisition framework which allows easy driver
development for anything that is analogue and digital IO. This
would be very useful to have this enabled in the kernel. I'm
developer of the USBDUX boards and I use the raspberry PI
in conjunction with these boards:
http://www.linux-usb-daq.co.uk/software2/rpi/
However in order to use the boards I need to re-compile the
kernel. I've also developed a small add on card for the RPI
which could serve as an example how to write drivers for
this framework:
http://web.eng.gla.ac.uk/rpi/

Hello Bernd,

Do you have any of the add-on cards for the RPI? I would love
to have one to test with comedi.

BTW, I would also love to have one of the USBDUX boards to
test with. :-)

Are you planning on submitting a driver for this board?

Regards,
Hartley

—
Reply to this email directly or view it on GitHub
#534 (comment).

www: http://www.linux-usb-daq.co.uk/
http://www.berndporr.me.uk/
http://www.imdb.com/name/nm3293421/
Mobile: +44 (0)7840 340069
Work: +44 (0)141 330 5237
University of Glasgow
School of Engineering
72 Oakfield Avenue (Rankine Building for deliveries)
Glasgow, G12 8LT

@berndporr
Copy link
Contributor Author

CONFIG_COMEDI=m
CONFIG_COMEDI_DEFAULT_BUF_SIZE_KB=2048
CONFIG_COMEDI_DEFAULT_BUF_MAXSIZE_KB=20480
CONFIG_COMEDI_MISC_DRIVERS=y
CONFIG_COMEDI_USB_DRIVERS=y
CONFIG_COMEDI_DT9812=m
CONFIG_COMEDI_USBDUX=m
CONFIG_COMEDI_USBDUXFAST=m
CONFIG_COMEDI_USBDUXSIGMA=m
CONFIG_COMEDI_VMK80XX=m
CONFIG_COMEDI_8255=m
CONFIG_COMEDI_FC=m

that enables the USB based drivers and a couple of other drivers which might be useful.

@graeme-hattan
Copy link

I've just made a new custom kernel for the B+:
http://www.linux-usb-daq.co.uk/software2/rpi/
It would be really great if you guys could enable comedi on the RPI kernel by default (see above). That would then allow all USB based data acquision devices to be used out of the box with the RPI. I've got a couple of customers who use the USB-DUX with the RPI and it's a real pain for them to download my comedi enabled kernel from the webpage and then untar them over the standard Raspbian image. Ubuntu and other distros have the comedi kernel drivers enabled by default but not the Raspbian.
I would really appreciate your help here. /Bernd

@Ruffio
Copy link

Ruffio commented Aug 10, 2016

@berndporr has this issue been resolved? If yes, then please close this issue.

@Ruffio
Copy link

Ruffio commented Aug 29, 2016

@popcornmix please consider closing this issue as there haven't been any activity since Oct 2014 and no response to my ping 19 days ago.

popcornmix pushed a commit that referenced this issue Sep 15, 2020
@osctobe @broonie
regulator: push allocation in regulator_ena_gpio_request() out of lock
467bf30 
Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.

WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       kmem_cache_alloc_trace+0x40/0x1e8
       regulator_register+0x384/0x1630
       devm_regulator_register+0x50/0x84
       reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);
  lock(regulator_list_mutex);

 *** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
 #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]

Fixes: 541d052 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
popcornmix pushed a commit that referenced this issue Sep 28, 2020
@osctobe @gregkh
regulator: push allocation in regulator_ena_gpio_request() out of lock
6916346 
[ Upstream commit 467bf30 ]

Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.

WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       kmem_cache_alloc_trace+0x40/0x1e8
       regulator_register+0x384/0x1630
       devm_regulator_register+0x50/0x84
       reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);
  lock(regulator_list_mutex);

 *** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
 #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]

Fixes: 541d052 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
popcornmix pushed a commit that referenced this issue Sep 28, 2020
@osctobe @gregkh
regulator: push allocation in regulator_ena_gpio_request() out of lock
8dc8bed 
[ Upstream commit 467bf30 ]

Move another allocation out of regulator_list_mutex-protected region, as
reclaim might want to take the same lock.

WARNING: possible circular locking dependency detected
5.7.13+ #534 Not tainted
------------------------------------------------------
kswapd0/383 is trying to acquire lock:
c0e5d920 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x54/0x2c0

but task is already holding lock:
c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:
       fs_reclaim_acquire.part.11+0x40/0x50
       fs_reclaim_acquire+0x24/0x28
       kmem_cache_alloc_trace+0x40/0x1e8
       regulator_register+0x384/0x1630
       devm_regulator_register+0x50/0x84
       reg_fixed_voltage_probe+0x248/0x35c
[...]
other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(fs_reclaim);
                               lock(regulator_list_mutex);
                               lock(fs_reclaim);
  lock(regulator_list_mutex);

 *** DEADLOCK ***
[...]
2 locks held by kswapd0/383:
 #0: c0e38518 (fs_reclaim){+.+.}-{0:0}, at: __fs_reclaim_acquire+0x0/0x50
 #1: cb70e5e0 (hctx->srcu){....}-{0:0}, at: hctx_lock+0x60/0xb8
[...]

Fixes: 541d052 ("regulator: core: Only support passing enable GPIO descriptors")
[this commit only changes context]
Fixes: f8702f9 ("regulator: core: Use ww_mutex for regulators locking")
[this is when the regulator_list_mutex was introduced in reclaim locking path]

Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/41fe6a9670335721b48e8f5195038c3d67a3bf92.1597195321.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@berndporr
Copy link
Contributor Author

Since the COMEDI drivers are still removed from the RPI kernel I've extracted the sources from the vanilla kernel and made them compile outwidth of the kernel:
https://github.com/glasgowneuro/comedi_raspberry_pi_bullseye

See also this thread:
https://groups.google.com/g/comedi_list/c/tBYH4iQeL14/m/iL5r4wlNBAAJ

Note the USB-DUX boards are now open hard- and software: https://github.com/glasgowneuro/usbdux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@popcornmix @graeme-hattan @bigguiness @berndporr @Ruffio