On Fri, 2011-04-15 at 02:07 +0200, Peter Stuge wrote:
Jeremy Moles wrote:
working great now .. via userspace
..
However, I'd like to be able to toggle the power on via a kernel driver as well,
Why?
but I'm having trouble accessing the same memory range from kernelspace.
For example:
iotools io_read8 0xA00
io_read8 is not a memory access, it is an I/O access. x86 has two different address spaces on the bus, and different instructions to access them.
The superio is not memory mapped..
When I try to do the same thing in the kernel:
unsigned short b; unsigned short* ptr = (unsigned short*)(0xA00);
if(access_ok(VERIFY_READ, ptr, 8)) { get_user(b, ptr);
...I immediately get a segfault.
..so that's not the way to reach it. Last time I did this I used inb() and outb(). Remember to use barriers as neccessary and also make sure that request_region() succeeds before you touch any hardware.
The proper way to implement GPIO support is btw to write a gpio class driver for it. There are lots of gpio drivers already in the kernel. I would actually not be surprised if your chip is already supported by one of them, and if not one could probably be extended easily. The GPIO drivers are exposed to userspace via sysfs.
Again; why does your other kernel driver need to deal with this GPIO? This smells like a questionable design decision was made somewhere in the chain. Better fix that sooner than later in that case..
It's really just an exercise to see whether it can be done or not. I thought it might be interesting to continue to experiment with the hardware a bit more. The real code to control the device is just a bash script using iotools.
However, using inb() doesn't change anything; it still panics the kernel immediately. There must be some kernel setup I'm mising... oh well.
//Peter