Linux - Embedded & Single-board computerThis forum is for the discussion of Linux on both embedded devices and single-board computers (such as the Raspberry Pi, BeagleBoard and PandaBoard). Discussions involving Arduino, plug computers and other micro-controller like devices are also welcome.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I am trying to find out of it is possible to pinmux and then load the spidev struct from userspace on a beaglebone. The spidev documentation states:
DEVICE CREATION, DRIVER BINDING
26The simplest way to arrange to use this driver is to just list it in the
27spi_board_info for a device as the driver it should use: the "modalias"
28entry is "spidev", matching the name of the driver exposing this API.
29Set up the other device characteristics (bits per word, SPI clocking,
30chipselect polarity, etc) as usual, so you won't always need to override
32 33(Sysfs also supports userspace driven binding/unbinding of drivers to
34devices. That mechanism might be supported here in the future.)
36When you do that, the sysfs node for the SPI device will include a child
37device node with a "dev" attribute that will be understood by udev or mdev.
38(Larger systems will have "udev". Smaller ones may configure "mdev" into
39busybox; it's less featureful, but often enough.) For a SPI device with
40chipselect C on bus B, you should see:
42 /dev/spidevB.C ... character special device, major number 153 with
43 a dynamically chosen minor device number. This is the node
44 that userspace programs will open, created by "udev" or "mdev".
46 /sys/devices/.../spiB.C ... as usual, the SPI device node will
47 be a child of its SPI master controller.
49 /sys/class/spidev/spidevB.C ... created when the "spidev" driver
50 binds to that device. (Directory or symlink, based on whether
51 or not you enabled the "deprecated sysfs files" Kconfig option.)
53Do not try to manage the /dev character device special file nodes by hand.
54That's error prone, and you'd need to pay careful attention to system
55security issues; udev/mdev should already be configured securely.
57If you unbind the "spidev" driver from that device, those two "spidev" nodes
58(in sysfs and in /dev) should automatically be removed (respectively by the
59kernel and by udev/mdev). You can unbind by removing the "spidev" driver
60module, which will affect all devices using this driver. You can also unbind
61by having kernel code remove the SPI device, probably by removing the driver
62for its SPI controller (so its spi_master vanishes).
64Since this is a standard Linux device driver -- even though it just happens
65to expose a low level API to userspace -- it can be associated with any number
66of devices at a time. Just provide one spi_board_info record for each such
67SPI device, and you'll get a /dev device node for each device.
Does this mean that support for it is not available but could be implemented?