some first impressions

[Jim Gettys]

Mitch,

There are ALSA controls defined for the analog input features.  So we
already have driver support.
                           - Jim


On Thu, 2007-08-16 at 09:24 -1000, Mitch Bradley wrote:
> Yoshiki Ohshima wrote:
> >   Mitch,
> >
> >   
> >>>   Thank you.  As I wrote on http://dev.laptop.org/ticket/2800, what we
> >>> would like to have is C functions.  Then, I can wrap them as Squeak
> >>> primitives.  Probably I can just rip these functions from amixer, but
> >>> if you can tell me which, that would be good!
> >>>   
> >>>       
> >> This is the relevant excerpt from the reference cited above.  The 
> >> correspondence between this and C code should be obvious (os.system() -> 
> >> system()), and it also implicitly answers the second question too.
> >>     
> >
> >   Yes, I know. But calling system() is not quite nice in various ways.
> > I'd rather would like to have a minimal C-code that can be a part of
> > the Squeak VM.
> >   
> The controls in question reside in registers that cannot be accessed 
> directly from userland programs
> 
> The mechanisms for accessing those registers are rather dependent on the 
> programming environment and its facilities for interacting with the OS.
> 
> The AC/DC control is the 0x02 bit in the Cs5536 GPIO register.    The 
> GPIO output value register is a 32-bit register at location 0x1000 in 
> I/O space. Conceptually, the operation you would have to perform is either:
> 
>    outl(0x02, 0x1000);  // AC mode
> or
>   outl(0x02 << 16, 0x1000);   // DC mode
> 
> The catch is that you can't do I/O space accesses from userland, unless
> 
> a) You use iopl() to grant the process extra permissions
> b) You use ioperm() to grant access to specific I/O registers (which 
> doesn't work in this case because the register number is too high)
> c) You access the I/O space via write() to /dev/port - which requires 
> extra permissions to open.
> 
> Which of these approaches is appropriate for your environement, I cannot 
> guess.
> 
> It might be nice if there were a driver to access the GPIO, but I didn't 
> see one in a quick scan of the kernel source.
> 
> The bias control is the 0x04 bit of codec register 0x76.  Accessing 
> codec registers requires a complicated dance involving some protected 
> (in the sense that they are not trivially accessible from userland) 
> registers in the AC97 hardware block.
> 
> As far as I know, the only extant C code for twiddling those registers 
> is the alsamixer code, which I presume that you can read as easily as we 
> can.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
-- 
Jim Gettys
One Laptop Per Child