Writing I2C support code - questions (maybe a bit offtopic?)
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
dpates@dsdk12.net | District (dsdk12.net) | #linuxOS on OPN
Reply to: