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
>
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
