I'm working on writing the support code for the KeyLargo I2C controller, so that the DACA chip's (a) sample rate and (b) config register can be manipulated. This should, I hope, fix the problem with noisy output after sleep on the iBook (I don't have an iceBook, but maybe this will be useful for the Tumbler as well). However, I have a couple quick questions:
- I'm using the Darwin DACA driver (from CVS) as a reference for how to program the I2C interface. Is this going to introduce licensing problems? I'm not a lawyer, so I don't really know. - This is, from all I've read, a regular (apparently bit-banging style) I2C interface. Right now, I'm just coding directly into the dmasound_awacs driver to get it supported appropriately, then I'll move the codde out andd clean it up once I get something functional. Should I move the I2C driver code (for the KeyLargo I2C bus, whose only inhabitant is the DACA control interface) into the I2C subsystem, and make the code for twiddling the I2C interface optional depending on whether or not the appropriate I2C driver is enabled? Should the DACA (and maybe Tumbler?) support code be split into a separate driver? Or should it just all be one driver, with an extra option for DACA(/Tumbler?) I2C control support? I'm so far just getting the I2C interface initialized and reading back the registers. I'd rather know before I go too far if I even can do this the way I am, and if so, if I'm going about it right. It doesn't look like it should be too hard to program, but without some sort of reference, it's confusing. Ben? Michel? Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet [EMAIL PROTECTED] | District (dsdk12.net) | #linuxOS on OPN
