• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 511 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Accessing Registers Directly in Driver

Ken Koller
Intellectual 770 points

Hi,

This is my first experience using embedded Linux but I have done lots of development using Real-Time kernels on embedded platforms. In the world I come from I can manipulate registers directly. I understand that user space among other things will have its own virtual memory space so that I cannot readily read or write directly to the devices peripheral registers. But can I write a driver and access these directly from kernel space?

The simplest example--and something I need to do--is to manipulate a GPIO. From my low-level experience I understand that there will exist many registers to set things like whether it is an input or an output or whether or not it is open-drain or whether to enable pull-ups or which functionality is muxed to the pin etc. The examples I've seen folks post (and thanks for posting) is within their driver they will call these gpio routines that I have seen described as being for use inside drivers rather than by the user.

Are these gpio calls simply added to abstract access to the GPIO registers? Or is there some other purpose?

Why not simply manipulate these registers directly from driver? In my opinion the code would be cleaner and a bit more efficient.

Being very comfortable writing to these registers I'd like to cut out the middle man but I suspect there are reasons he exists.

Regarding writing kernel drivers is this generally pretty simple, i.e. not much different than writing user space code? If not, will someone recommend a useful resource for learning how to do this correctly?

Thanks,

Ken

  • 0
    TI__Mastermind 41665 points

    Ken Koller said:
    I understand that user space among other things will have its own virtual memory space so that I cannot readily read or write directly to the devices peripheral registers. But can I write a driver and access these directly from kernel space?

    This is true, but you certainly can write such a driver which even gives you access from user/application space, and this has actually been done before, for example take a look at this, or depending on the device and DVSDK version you are using you may have one built into one of your existing drivers already.

    Ken Koller said:

    Are these gpio calls simply added to abstract access to the GPIO registers? Or is there some other purpose?

    Why not simply manipulate these registers directly from driver? In my opinion the code would be cleaner and a bit more efficient.

    Being very comfortable writing to these registers I'd like to cut out the middle man but I suspect there are reasons he exists.

    Once you are in driver space you can access registers directly if you prefer, often calls are abstracted like this to make the code look more human readable as well as being more portable across platforms (i.e. you have a bunch of high level GPIO code that works on all platforms and just a low level translation layer for each specific target), however if you are only working on one piece of hardware and prefer a more direct register accessing route you can do it that way.

    Ken Koller said:
    Regarding writing kernel drivers is this generally pretty simple, i.e. not much different than writing user space code? If not, will someone recommend a useful resource for learning how to do this correctly?

    It is all C code so it is similar to user space code, however there are some kernel APIs to use and rules to follow, in addition to being more difficult to debug in some ways, since if you have a bad pointer it doesn't just crash the driver, but it can bring down the entire system. One resource that you may find helpful is Linux Device Drivers 3rd Edition, though this is starting to age a bit it can be helpful in walking through the device driver concept and act as a reference for some key APIs.