| *** pH5 has quit IRC | 00:24 | |
| *** csaavedra has quit IRC | 00:41 | |
| *** nonick has quit IRC | 01:12 | |
| *** _0x47 has quit IRC | 02:16 | |
| MNZ | DocScrutinizer, I read the alsa api a bunch. Documentation is not all that great. I think the best way to expose the coefficients would be through a 'hardware dependent device' | 02:40 |
|---|---|---|
| MNZ | basically I implement a bunch of callbacks and register with the alsa system, and userspace can access it through libalsa abstraction | 02:41 |
| MNZ | and it's not a mixer control, because it really shouldn't be | 02:41 |
| DocScrutinizer | logically it should, but meh | 02:42 |
| MNZ | no I mean if it's going to be coeffs, then it obviously shouldn't be mixer controls' | 02:43 |
| MNZ | if it was going to be levels/gain, then yeah I guess | 02:43 |
| DocScrutinizer | the raw coeffs obviously don't fit into alsa mixer | 02:44 |
| MNZ | so final thoughts, should I go this way? | 02:44 |
| DocScrutinizer | doesn't make sense to adjust coeff values via sliders :-P | 02:44 |
| DocScrutinizer | sound good | 02:44 |
| DocScrutinizer | honestly, as long as there's any reasonable way to shoot the raw coeff values to the chip, it's much better than now | 02:46 |
| DocScrutinizer | everything beyond probably has to be done in userspace anyway | 02:47 |
| MNZ | Agreed | 02:47 |
| DocScrutinizer | maybe it's best to expose the coeff registers as /sys or /dev, and have a "plugin" for ALSA (analog to e.g. softvol, regarding sliders etc) which implements >>control.16 {comment.access 'read write'; comment.type ENUMERATED; comment.count 1; comment.item.0 'off'; comment.item.1 'lowpass filter'; comment.item.2 'bandpass'; <etc>iface MIXER; name 'Parametric Filter A Type'; value 'off'} | 03:03 |
| DocScrutinizer | etc etc for freq (also an enum to select of 4 or 5 f0), for bandwidth/Q, and for gain (range -24 .. +24dB, step 3) | 03:05 |
| MNZ | adding it as hwdep (hardware dependent device) adds a device file AIUI | 03:05 |
| MNZ | with the added benefit of access through libalsa | 03:06 |
| DocScrutinizer | then just select from a 4 dimensional array of tupels of precalculated coeffs | 03:06 |
| MNZ | I don't recall whether alsa plugins are kernelland or userland | 03:07 |
| DocScrutinizer | for an array of coeffs that's rather irrelevant | 03:07 |
| MNZ | oh right | 03:08 |
| MNZ | but what about the parametric eq? it wouldn't be fully configurable any more right? | 03:08 |
| DocScrutinizer | 4 types * 5 f0 * [-24..+24 / 3 ] * arbitrary_number_of_Q | 03:09 |
| DocScrutinizer | not from ALSA via mixer control | 03:10 |
| DocScrutinizer | you'd need a userland app switching the filter to off mode in ALSA mixer, and poking the values directly, after doing the numbercrunching | 03:10 |
| DocScrutinizer | for fully parametric | 03:11 |
| DocScrutinizer | in ALSA mixer API you are restricted to the set of predefined steps for each parameter | 03:11 |
| DocScrutinizer | (4 types * 5 f0 * ...) | 03:12 |
| MNZ | sorry but I haven't really dealt with alsa plugins before except dmix | 03:12 |
| *** jacktheripper has quit IRC | 03:12 | |
| MNZ | so this plugin would expose mixer controls? | 03:12 |
| DocScrutinizer | check out softvol | 03:12 |
| DocScrutinizer | it appears in mixer after you do a alsactl restore | 03:13 |
| DocScrutinizer | even while the real 'plugin' isn't used at that moment in any audio stack, still the sliders in mixer appear | 03:14 |
| MNZ | but if we are just exposing mixer controls then why not in the codec driver in the first place :S ? | 03:14 |
| DocScrutinizer | I'm fine with that, if that's feasible and won't conflict with the /dev or /sys approach | 03:15 |
| MNZ | no it won't. both can be done | 03:15 |
| DocScrutinizer | refer to http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.new control 16 .. 19 for inspiration | 03:20 |
| MNZ | the only reason to have prebaked coeffs would be for easy changing of filter from command line I suppose. If there's going to be a userland gui then we might as well go the extra mile and have it do full blown parametric (calculate own coeffs) and store presets, etc | 03:29 |
| *** SpeedEvil has quit IRC | 03:30 | |
| DocScrutinizer | that's exactly what I said above | 03:32 |
| DocScrutinizer | <DocScrutinizer> you'd need a userland app switching the filter to off mode in ALSA mixer, and poking the values directly, after doing the numbercrunching | 03:33 |
| MNZ | yes I wasn't adding anything except 'the only reason to'. | 03:33 |
| DocScrutinizer | aah, k | 03:33 |
| MNZ | what I was saying is basically what is the point of prebaked values | 03:33 |
| DocScrutinizer | the real reason I think is we don't want thinks like arctan() in kernel ;-D | 03:34 |
| DocScrutinizer | thigs | 03:34 |
| DocScrutinizer | bah! things now | 03:34 |
| MNZ | yeah, then no values at all and just let the userland app do the magic | 03:34 |
| MNZ | tbh the look up table thing will be too much uncool work to do ;P | 03:35 |
| MNZ | lemme just get the hwdep working first :D | 03:35 |
| DocScrutinizer | and as ALSA is kernel space (I guess) that's the rationale not to have full blown parametric in ALSA mixer API, but a somewhat reduced set as like control16..19 in above mentioned/linked statefile | 03:36 |
| MNZ | I understand, except that it's not really 'reduced' :D | 03:37 |
| DocScrutinizer | I did a oopsie, the ALSA of course will be reduced, as it doesn't have choice of filter Q or filter type I'd say. A simple bass+treble will suffice | 03:38 |
| MNZ | I suppose that would not be too much trouble. | 03:39 |
| DocScrutinizer | as the next sweetspot is full parametric which would need at least 3 freq/octave | 03:39 |
| DocScrutinizer | with just 5 f0 a parametric approach is nonsense | 03:40 |
| DocScrutinizer | so no switchin to different filter types, just on/off. No more than 4 f0, no Q even or maybe make that just 12dB/6dB per octave. Just a slider to go from -24dB to +24dB in 3dB steps | 03:43 |
| DocScrutinizer | the filter state might have a 3rd state beneath on and of: "user defined" which means same as off for ALSA and isn't selectable but is triggered by writing raw coeffs to the /sys registers | 03:45 |
| MNZ | ah, right. I believe that's all cases covered | 03:46 |
| MNZ | I'm working on the device interface now, will finish that then get zzzz time. | 03:47 |
| DocScrutinizer | so as soon as the userland full parametric app starts messing with the bi-quad coeffs, the ALSA mixer filter state goes to "user defined" | 03:47 |
| *** lcuk2 has joined #maemo-devel | 03:49 | |
| *** lcuk has quit IRC | 03:52 | |
| *** SpeedEvil has joined #maemo-devel | 04:01 | |
| MNZ | oh welll, time for zzzz | 04:07 |
| *** MNZ has quit IRC | 04:07 | |
| *** SpeedEvil1 has joined #maemo-devel | 04:19 | |
| *** SpeedEvil has quit IRC | 04:21 | |
| *** SpeedEvil1 is now known as SpeedEvil | 04:39 | |
| *** shinkamui has joined #maemo-devel | 04:58 | |
| *** kamui__ has quit IRC | 05:01 | |
| *** Milhouse has quit IRC | 05:26 | |
| *** Milhouse has joined #maemo-devel | 05:27 | |
| *** swc|666 has joined #maemo-devel | 05:51 | |
| *** SpeedEvil has quit IRC | 06:07 | |
| *** kamui__ has joined #maemo-devel | 06:17 | |
| *** shinkamui has quit IRC | 06:21 | |
| *** SpeedEvil has joined #maemo-devel | 06:23 | |
| *** SpeedEvil has quit IRC | 06:28 | |
| *** SpeedEvil has joined #maemo-devel | 06:43 | |
| *** kamui__ has quit IRC | 07:15 | |
| *** fiferboy has quit IRC | 07:25 | |
| *** DocScrutinizer has quit IRC | 07:31 | |
| *** DocScrutinizer has joined #maemo-devel | 07:31 | |
| *** swc|666 has quit IRC | 09:07 | |
| *** swc|666 has joined #maemo-devel | 09:08 | |
| *** lmoura has quit IRC | 09:45 | |
| *** lmoura has joined #maemo-devel | 09:46 | |
| *** lmoura has quit IRC | 10:10 | |
| *** povbot has joined #maemo-devel | 10:18 | |
| *** swc|666 has quit IRC | 10:23 | |
| *** lmoura has quit IRC | 10:35 | |
| *** csaavedra has joined #maemo-devel | 10:39 | |
| *** lmoura has joined #maemo-devel | 10:39 | |
| *** achipa has joined #maemo-devel | 10:46 | |
| *** amigadave has joined #maemo-devel | 10:48 | |
| *** yaozhuang has joined #maemo-devel | 10:55 | |
| *** JPohlmann has joined #maemo-devel | 11:01 | |
| *** achipa has quit IRC | 11:04 | |
| *** yaozhuang has left #maemo-devel | 11:06 | |
| *** Psi has joined #maemo-devel | 11:09 | |
| Psi | anyone here using/used lazarus/fpc for mameo? | 11:10 |
| *** lmoura has quit IRC | 11:44 | |
| *** radegand has joined #maemo-devel | 11:45 | |
| *** lmoura has joined #maemo-devel | 11:54 | |
| *** lmoura has quit IRC | 12:01 | |
| *** dazo_afk is now known as dazo | 12:03 | |
| *** MNZ has joined #maemo-devel | 12:11 | |
| *** lmoura has joined #maemo-devel | 12:15 | |
| *** JPohlmann has quit IRC | 12:19 | |
| *** _0x47 has joined #maemo-devel | 12:45 | |
| *** JPohlmann has joined #maemo-devel | 13:07 | |
| *** lcuk2 is now known as lcuk | 13:16 | |
| *** lcuk has joined #maemo-devel | 13:16 | |
| *** mirr0r has joined #maemo-devel | 13:40 | |
| *** lizardo has joined #maemo-devel | 13:48 | |
| *** r3pek has joined #maemo-devel | 14:50 | |
| r3pek | hey guys | 14:50 |
| r3pek | what arch is n770? | 14:50 |
| r3pek | want to built its toolchain on gentoo | 14:50 |
| *** lmoura has quit IRC | 15:18 | |
| *** alvaro__ has joined #maemo-devel | 15:24 | |
| *** lmoura has joined #maemo-devel | 15:31 | |
| *** lmoura_ has joined #maemo-devel | 15:47 | |
| *** lmoura has quit IRC | 15:50 | |
| *** lmoura__ has joined #maemo-devel | 15:53 | |
| *** lmoura_ has quit IRC | 15:53 | |
| *** r3pek has left #maemo-devel | 15:59 | |
| *** fiferboy has joined #maemo-devel | 16:01 | |
| *** fiferboy has quit IRC | 16:01 | |
| *** fiferboy has joined #maemo-devel | 16:01 | |
| *** achipa has joined #maemo-devel | 16:06 | |
| *** csaavedra has quit IRC | 16:46 | |
| *** csaavedra has joined #maemo-devel | 16:51 | |
| *** csaavedra has quit IRC | 17:01 | |
| *** achipa has quit IRC | 17:09 | |
| *** lmoura__ has quit IRC | 17:11 | |
| *** lmoura has joined #maemo-devel | 17:12 | |
| MNZ | DocScrutinizer, ping | 17:24 |
| DocScrutinizer51 | hm | 17:24 |
| MNZ | a bunch of quick cleanups and I'm testing the hwdep code, and the on/off/preset. Though presets haven't been calculated | 17:24 |
| MNZ | I'm just facing a small locking problem: | 17:25 |
| MNZ | There are 2 pages of registers, coefficient registers are on page 1, while page 0 contains everything else | 17:25 |
| MNZ | now the driver was originally written ignoring the existence of page 1 | 17:25 |
| MNZ | so whenever I write coeffs, I change page, write regs, change back. So that everything else doesn't have to worry | 17:26 |
| DocScrutinizer51 | mhm | 17:27 |
| MNZ | I just realized that you could theoretically corrupt the registers by accessing say the hwdep device and writing coeffs and in the few milliseconds it takes to finish the write you mess with volumes somehow | 17:27 |
| DocScrutinizer51 | hm I see | 17:27 |
| MNZ | so it's wither a big ass mutex (which I suspect exists already, but I've been going up the code stack and haven't hit it yet) | 17:28 |
| DocScrutinizer51 | how's page switching done? | 17:28 |
| MNZ | s/wither/either/ | 17:28 |
| MNZ | page switching is just another reg, you write 1 or 0 to it | 17:28 |
| DocScrutinizer51 | I see | 17:29 |
| MNZ | or I could ignore the problem | 17:29 |
| DocScrutinizer51 | I think I2C access for one action is atomic | 17:29 |
| DocScrutinizer51 | so of you can manage to crowd everything incl switching to a single write... | 17:30 |
| MNZ | unfortunately that would be harder than big-ass-mutex | 17:31 |
| MNZ | thing is I'm not entirely sure this is really a problem | 17:31 |
| DocScrutinizer51 | locj the I2C device? | 17:31 |
| *** SpeedEvil has quit IRC | 17:33 | |
| MNZ | I thought of that, but it still doesn't alleviate the problem, the lock can't be that far down | 17:33 |
| MNZ | (if you mean lock the device before each write) | 17:33 |
| MNZ | because it's several writes. | 17:33 |
| MNZ | locking needs to happen at much higher level, and if I do that I would have to add locking code to a lot of the original code | 17:34 |
| MNZ | do you reckon there actually can arise a situation where this 'bug' will show? | 17:34 |
| *** SpeedEvil has joined #maemo-devel | 17:35 | |
| DocScrutinizer51 | aiui e.g. the bq27200 registers are not accessable via bme when kernel has opened the I2C for the bq27k /sys | 17:36 |
| *** jacktheripper has joined #maemo-devel | 17:36 | |
| DocScrutinizer51 | I don't think a collision is frequently occuring and also should't cause too much demolition | 17:38 |
| SpeedEvil | umm | 17:39 |
| SpeedEvil | isn't the aic34b module the only thing that will touch it? | 17:39 |
| SpeedEvil | Or am I misunderstanding | 17:39 |
| MNZ | believe me it's a lot of demolition if the wrong page is active.... | 17:39 |
| DocScrutinizer51 | generally if you keep the writes close in a sequence in your code, odds are central dispatcher won't preemt to allow another process to interfere | 17:40 |
| MNZ | SpeedEvil, aic3x codec driver. It will be the only thing touching it, yes, but there's more than one way to access it | 17:40 |
| SpeedEvil | Surely you just implement the locking in the driver | 17:40 |
| SpeedEvil | So itr doresn't do conflicting accesses to I2C | 17:40 |
| DocScrutinizer51 | MNZ: you won't accidentally write to pahe 0 | 17:40 |
| MNZ | DocScrutinizer51, that's what I'm thinking as well. The writes are all one after the other and page is back to 0 immediately | 17:41 |
| DocScrutinizer51 | it's just the volume could ruin your filter setting | 17:41 |
| DocScrutinizer51 | anyway SpeedEvil 's pooint is valid | 17:42 |
| MNZ | SpeedEvil, the driver was written ignoring the presence of another page of registers, so locking is non-existent. | 17:42 |
| MNZ | that's a whole bunch of locking to add all over the place | 17:43 |
| MNZ | and I'm not even sure how/where to add it, as it needs to be add at a relative high level, and this isn't always possible | 17:43 |
| MNZ | like when accessing through alsa controls, there're a bunch of prewritten callbacks that just take different params. So locking inside them is not possible | 17:44 |
| MNZ | unless I change all the callbacks to my own (which is basically rewriting 70% of the driver, and a lot of unnecessary code) | 17:45 |
| DocScrutinizer | MNZ: gimme a URL to the existing code where locking needs to take place | 17:46 |
| DocScrutinizer | preferably mxr.maemo.org | 17:47 |
| MNZ | there're a lot of mutex within alsa completely above any entry point to the driver anyway, and though I haven't confirmed it yet I think it would be really difficult or impossible to corrupt the registers the way I'm thinking | 17:47 |
| SpeedEvil | Add a I2C function that takes an atomic parameter. | 17:47 |
| DocScrutinizer | SpeedEvil: exactly what I was thinking bout | 17:47 |
| MNZ | what does 'atomic parameter' mean? | 17:48 |
| MNZ | current code is http://mxr.maemo.org/fremantle/source/kernel/sound/soc/codecs/tlv320aic3x.c | 17:48 |
| DocScrutinizer | replace I2C_write_AIC34(reg, value) by I2C_write_AIC34(page, reg, value) | 17:48 |
| SpeedEvil | A parameter that lets you do all of the required actions in one call | 17:49 |
| DocScrutinizer | inside I2C_write_AIC34() have a local lock to avoid reentrance | 17:50 |
| MNZ | that would entail rewriting most the driver :/ | 17:50 |
| DocScrutinizer | nope | 17:50 |
| MNZ | everywhere there's an aic3x_write() | 17:50 |
| MNZ | not rewriting | 17:50 |
| MNZ | I mean adding that param | 17:50 |
| MNZ | everywhere | 17:50 |
| DocScrutinizer | nope, still nope | 17:50 |
| MNZ | ? | 17:50 |
| *** amigadave has quit IRC | 17:51 | |
| MNZ | (btw look at line 334, that's where the alsa controls are defined) | 17:51 |
| DocScrutinizer | you only replace aic3x_write() {foo bar blub} by aic3x_write() {aic3x_write_2(PAGE0, $1, $1);} | 17:52 |
| MNZ | oh right. macros FTW | 17:53 |
| DocScrutinizer | inside new function aic3x_write_2() you do the locking, and also this new function is what you call for EQ | 17:53 |
| DocScrutinizer | that's nothing avout macros | 17:53 |
| MNZ | yeah it could be a new function, or just a macro that sets the page arg to 0 | 17:54 |
| MNZ | but in any case, you mean I'd do the locking inside the function, or explicitly set the page before each write? | 17:54 |
| DocScrutinizer | a macro still has to affect every sourcecode line where the func() is called aiui | 17:54 |
| DocScrutinizer | code now does aic3x_write(reg, value) which is implicitly to page0 | 17:55 |
| DocScrutinizer | you rewrite that function to call a new function aic3x_write_2(PAGE0, reg, value) | 17:56 |
| DocScrutinizer | inside aic3x_write_2(){} you do the locking | 17:56 |
| MNZ | I do the locking AND set the page before each write | 17:57 |
| DocScrutinizer | yes | 17:57 |
| MNZ | that would work perfectly, though that's a lot of overhead | 17:57 |
| DocScrutinizer | doesn't matter | 17:57 |
| DocScrutinizer | we got no data volume | 17:57 |
| MNZ | and that just doubled the data going down the I2C line | 17:58 |
| MNZ | sure it doesn't matter ? | 17:58 |
| DocScrutinizer | yes | 17:58 |
| DocScrutinizer | this whole cruft is called one time every few hours | 17:58 |
| *** Ian-- has quit IRC | 17:58 | |
| DocScrutinizer | overhead is irrelevant | 17:58 |
| DocScrutinizer | if you want optimize, you have a local static var keeping state of page-select-reg, and you skip setting to page x if that local var tells you the reg already is set to x | 18:04 |
| MNZ | damn I was just typing that | 18:04 |
| DocScrutinizer | first :-P | 18:04 |
| DocScrutinizer | make sure to initialize local static var to -1 or 9999 on module init | 18:06 |
| MNZ | thanks, was definitely going to miss that | 18:07 |
| *** pH5 has joined #maemo-devel | 18:08 | |
| DocScrutinizer | so call the var static int jOERG :-P | 18:09 |
| MNZ | lol :P | 18:09 |
| DocScrutinizer | static char ? | 18:11 |
| MNZ | what's wrong with ints? | 18:11 |
| DocScrutinizer | byte? word? shortint? | 18:11 |
| DocScrutinizer | dunno which type you'll need for it :-D | 18:12 |
| MNZ | doesn't matter really | 18:12 |
| DocScrutinizer | basically nothing wrong with int, just it's waste of space | 18:12 |
| MNZ | yeah, except I just added a whole bunch of overhead, do I really want to save 3 bytes? | 18:12 |
| *** Ian-- has joined #maemo-devel | 18:12 | |
| DocScrutinizer | and introduced a hidden cast | 18:12 |
| *** Weiss_ is now known as Weiss | 18:13 | |
| DocScrutinizer | but meh | 18:13 |
| DocScrutinizer | static I2C-reg page-register-latch | 18:13 |
| MNZ | the what now? :D | 18:14 |
| MNZ | besides, take a look at the aic3x_write() func. Talk about optimization :P | 18:16 |
| DocScrutinizer | the latch should probably have same type as the value for register which is passed down from self_parameterlist, and which also is used to call the actual I2Cwrite() | 18:16 |
| DocScrutinizer | duh, missed to look at your URL... | 18:16 |
| DocScrutinizer | mompls | 18:16 |
| MNZ | line 126 | 18:17 |
| DocScrutinizer | eew check codec->hw_write() and #166 ff | 18:22 |
| DocScrutinizer | esp #174 | 18:23 |
| MNZ | meh what's wrong with #174? just dumping cache into hw | 18:24 |
| MNZ | and codec->hw_write() = i2x_master_send. I haven't checked what that is but looks like a func from i2c subsystem | 18:26 |
| MNZ | the aic3x_write func though, blaaargghhh | 18:26 |
| MNZ | why the & 0xff. Why take unsigned ints in the first place. And there's a bug at #138 (reg cache is set even if hw_write() fail | 18:27 |
| DocScrutinizer | yeah, you'll need to take care about cache size, caching page1 as well, etc | 18:27 |
| MNZ | yeah, I cache coeffs in a different structure though. The usual reg caching was inconvenient for coeffs. | 18:29 |
| DocScrutinizer | and you need to implement locking and page selection around codec->hw_write() calls :-S | 18:29 |
| MNZ | oh. ohhhhh :S | 18:29 |
| MNZ | that's what's wrong with #174. *facepalm* | 18:29 |
| MNZ | well, it's only in three places besides write(). aic3x_reset/resume/probe() | 18:31 |
| MNZ | XD | 18:50 |
| MNZ | after adding the locking I realized I never once pass the page param to aic3x_write_2 XD | 18:51 |
| MNZ | the function for writing coeffs doesn't go through aic3x_write because of different caching and different method of writing registers | 18:51 |
| DocScrutinizer | I'd advocate it does, though | 18:52 |
| MNZ | so back to aic3x_write, do the locking in there, and locking inside aic3x_write_coeff, and 2 more places where aic3x_write is skipped | 18:52 |
| MNZ | the coeffs are unsigned short, need to split them into msb and lsb parts, as 2s compliment. I cache them as unsigned shorts though since that's how I need them most of the time | 18:53 |
| DocScrutinizer | static int aic3x_write(struct snd_soc_codec *codec, unsigned int reg, unsigned int value) {...}; where reg > NUM_OF_REG_PAGE0 means it's for page 1 | 18:55 |
| DocScrutinizer | don't forget it seems the aic3x_reset() *resume() etc seem to deal with restoring codec hw registers from cache after certain system events, like suspend etc | 18:57 |
| DocScrutinizer | so it seems highly advisable to keep page1 in same cache and code like page0 | 18:57 |
| MNZ | yes that's already taken care of | 18:58 |
| MNZ | I restore page1 first, then page0 | 18:58 |
| DocScrutinizer | aah, ok. | 18:58 |
| DocScrutinizer | I'd be willing to review source, once you think it's ok for that | 18:59 |
| *** w00t_ has left #maemo-devel | 19:01 | |
| MNZ | write now aic3x_write_coeff takes a signed short, caches it, converts to 2s compliment and splits to msb/lsb then hw_write(). It doesn't do the locking and page switching. I figured there will be 20 coeff writes in a row, so lock+page switch be left to caller | 19:01 |
| MNZ | s/^write/right/ | 19:01 |
| *** radegand has quit IRC | 19:02 | |
| DocScrutinizer | I'd not use hw_write directly, instead go via static int aic3x_write() and set reg to a value that indicates a register on page 1 rather than page0 | 19:03 |
| DocScrutinizer | do the splitting of int to msb/lsb before calling this function, and use the caching implemented inside static int aic3x_write() instead of your own caching | 19:04 |
| *** csaavedra has joined #maemo-devel | 19:05 | |
| DocScrutinizer | extend codec->reg_cache to hold page1 registers as well as page0 | 19:05 |
| MNZ | seems more reasonable than current way | 19:05 |
| DocScrutinizer | fix #175 | 19:05 |
| DocScrutinizer | as well as similar constructs elsewhere | 19:05 |
| MNZ | ok, working on it. hopefully this will be last change then test time | 19:06 |
| DocScrutinizer | :-) | 19:06 |
| *** Psi has quit IRC | 19:11 | |
| MNZ | I just noticed something.. in the restore() function, a lot of reserved bits in the registers are written over | 19:12 |
| DocScrutinizer | between 177 and 178 insert a test for i in page0 or page1, and switch pageing-register with an additional call to codec->hw_write(codec->control_data, SELECT_PAGE1, 2) | 19:13 |
| DocScrutinizer | resp SELECT_PAGE0 | 19:13 |
| MNZ | sorry I'm confused | 19:15 |
| MNZ | that doesn't solve it. I mean a lot of the registers have reserved bits that the datasheet says not to write to, but this overwrites them | 19:15 |
| MNZ | but it seems that hasn't been causing any problems anyway | 19:16 |
| DocScrutinizer | static int jOERG; if ( jOERG != i%NUM_REGS_PAGE0 ) { jOERG = i%NUM_REGS_PAGE0; codec->hw_write(codec->control_data, jOERG?SELECT_PAGE0:SELECT_PAGE1} | 19:17 |
| DocScrutinizer | something that looks a very little bit like that | 19:17 |
| DocScrutinizer | after #177 | 19:17 |
| DocScrutinizer | (write to bits) you can't avoid writing to single bits :-D | 19:18 |
| DocScrutinizer | just keep them what they've ever been | 19:19 |
| DocScrutinizer | or simply don't care | 19:19 |
| MNZ | which works for bits, but what about entire register ranges? | 19:19 |
| MNZ | we don't know how the codec is using them. I guess I should just skip those? | 19:20 |
| DocScrutinizer | keep them out of the refresh by comparing the i loop counter to a 'blacklist' | 19:20 |
| DocScrutinizer | yep, exactly | 19:20 |
| MNZ | instead of blacklisting and that clever way of switching pages, why not just write two loops :D ? | 19:22 |
| DocScrutinizer51 | up to you | 19:23 |
| *** _0x47 has quit IRC | 19:40 | |
| *** VDVsx has joined #maemo-devel | 19:41 | |
| *** csaavedra has quit IRC | 19:56 | |
| *** lmoura has quit IRC | 20:03 | |
| *** lmoura has joined #maemo-devel | 20:06 | |
| MNZ | DocScrutinizer, is there any point to have aic3x_write() take uint16 and explicitly do the '& 0xff' and assign to uint8? | 20:20 |
| *** dazo is now known as dazo_afk | 20:28 | |
| *** VDVsx has quit IRC | 20:36 | |
| DocScrutinizer | uint16? seems the call takes unsigned int where in my book int is 32bit even. Anyway there's no obvious particular sense in it | 20:38 |
| *** VDVsx has joined #maemo-devel | 20:39 | |
| DocScrutinizer | static int aic3x_write(struct snd_soc_codec *codec, unsigned int reg, unsigned int value) | 20:39 |
| *** JPohlmann has quit IRC | 20:39 | |
| *** JPohlmann1 has joined #maemo-devel | 20:39 | |
| DocScrutinizer | u8 data[2]; data[0] = reg & 0xff; data[1] = value & 0xff; | 20:39 |
| MNZ | I just changed it to static int aic3x_write(struct snd_soc_codec *codec, u8 reg, u8 value) | 20:40 |
| MNZ | and removed the & 0xff | 20:40 |
| *** csaavedra has joined #maemo-devel | 21:56 | |
| *** VDVsx has quit IRC | 22:09 | |
| *** onen|openBmap has joined #maemo-devel | 22:29 | |
| *** _0x47 has joined #maemo-devel | 22:54 | |
| MNZ | time for runtime bugs galore! | 23:31 |
| *** pH5 has quit IRC | 23:47 | |
| *** onen|openBmap has quit IRC | 23:47 | |
| *** lizardo has quit IRC | 23:53 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!