LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 02-10-2012, 08:17 AM   #1
tomsmith
LQ Newbie
 
Registered: Feb 2012
Posts: 1

Rep: Reputation: Disabled
Control status register simulation in memory


Hi,
I am writing a kernel module for a peripheral device and i need to simulate some of the registers on the device in memory. I have been trying to write this for a while with no luck. If anyone had any advice it would be a great help. Thanks
 
Old 02-10-2012, 08:36 AM   #2
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,599
Blog Entries: 4

Rep: Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905Reputation: 3905
I am afraid that, reading your post, I have utterly no idea what you are asking.

A very common technique that is used by device-drivers that need to allow userland at least to see some particulars about the status of the device is to implement ioctl() calls that will retrieve the necessary answers. The device block in Linux provides some memory-areas that are specifically intended to be the device driver's private playpen (either to use directly, or to use as a pointer to some kind of memory-block which it may allocate for itself). You could certainly use some of these to "shadow" the driver's latest-known awareness of what the device status-register values should be, so that your ioctl() handler could then retrieve it.
 
Old 02-10-2012, 09:54 AM   #3
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
I fully agree with sundialsvcs, except to point out that ioctls are not the preferred interface. Kernel modules adding new ioctls will be less likely to be accepted upstream (and therefore into distributions); you'll have to be prepared to explain exactly why you think ioctls are the best interface for this.

Personally, I'd recommend using plain character devices. For example, you might have one device file for raw data, and another for control messages. If the control messages are plain text, you can then control your device from simple shell scripts. (Not to mention that your kernel code will be very simple, and fully contained in your module.)

The only issue is synchronizing state changes to your device driver. You may have one CPU core running in the kernel accessing the driver state for raw data transfer, while another code runs in the kernel modifying the driver state due to a control message; both at the exact same time. This should be easy to avoid by protecting the state using a lock.

As to the actual driver, see Linux Device Drivers, Third Edition. If your device wants to export "registers" to user space, you can simply create a structure that mirrors the contents of these registers. (You should allocate it dynamically when your device is bound.)

To let userspace read the device similar to /proc/meminfo , add a read method to the control device driver. It must construct the "file" contents as a string, based on the values in the internal structure.

To let userspace modify the device state, add a write method to the control device driver. It could parse text control settings (like baudrate=38400), and modify the values in the state structure accordingly.



For good examples how these character-device based interfaces work, look at the kernel interfaces in /sys/. They work pretty much like I just described above, except that /sys/ device nodes are usually limited to a single value (instead of full device state), so that they're easier to extend later on. From userspaces point of view, this interface is much easier to use than one that requires ioctls(), because you just treat the devices as normal files.

If you can describe your device a bit more detail, I think I could describe this method much better. I am almost certain this is easier to maintain in the long term (compared to a driver using ioctl()s), and I believe it would be much easier to get included upstream, should you desire that now or later on.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
a working radio control helicopter simulation rob.rice Linux - General 2 12-12-2010 02:28 PM
[SOLVED] the same story, userspace accees error for a memory mapped control register pardis Linux - Embedded & Single-board computer 2 07-21-2010 06:49 AM
problem in read register status for at91rm9200 board goelmanila Linux - Newbie 0 06-26-2008 02:24 AM
Does 2.6 kernel support control register directly? LeoneVictor Linux - Kernel 0 04-18-2007 03:34 AM
Simulink / Control Systems / (Analog/Digital) Time domain Simulation tasamy Linux - Software 1 05-24-2006 05:32 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 06:34 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration