Trent Piepho wrote: > On Tue, 28 Aug 2007, Manu Abraham wrote: >> * use integer math calculations >> * precompute the values where double precision is needed. >> >> That said, the first option i tried for a while, after a few days (i >> almost gave up ?) got really irritated with it. >> The second option seemed a bit more comfortable, to precalculate the values. >> >> The disadvantage in such a case is that the array which holds the >> precomputed value is quite large in size, with that in mind, a different >> question arose in my mind, whether such large arrays would be frowned >> upon in kernel >> >> The precomputed array is here >> >> http://www.jusst.de/manu/mc44s80x_array.c >> >> Any thoughts ? > > That's really inefficient. You've got about 250k of table there. I don't > think a 250k+ module is going to be very popular. > I do agree that's not the most effecient way. But given the short time span and lack of FP operations, the quick way that came to my mind was precomputed values. That said, the popularity of a module is not defined by it's size. as an eg: the nVidia module is over 1 Meg. Considering the quality/performance of the tuners in the tree we have, i don't think there would even be a popularity contest, coming anywhere near. That said, if it can be optimized, there is no reason why it shouldn't be done. I had a comment from Andrew Morton as well on it: "It's large, but heck, it's not a lot of memory. The nvidia driver is a meg or something." > The table could be packed a lot better. None of the fields need to be 64-bit, > so don't use unsigned long which is 64 bits on 64 bit platforms. Most of > those fields don't even have 32 bits that change. For example, I can see that > the last 12-bits of the refdiv field are always 0x9b2. You could put that > field in 8-bits (or less, it looks like only 5 bits change). True. Darren Salt did some optimizations. The optimized version is here http://zap.tartarus.org/~ds/mc44s80x_test_packed_more.c If anyone's interested, the original version with FP is here: http://paste.debian.net/35554 It 's a userspace application with which i did some crude tests. The tables are here http://jusst.de/manu/1086M_36.125M.c http://jusst.de/manu/1086M_36.166M.c > The freq field looks like it's just every 1/6th MHz from 50 Mhz to 1 GHz. Why > do you need to store that? It should be trivial to calculate. The 166k increment is the step size, the step size would vary with different use cases. No need to store it, but the quick way (had just 2 days with me for completing it) was that. > unsigned int x; /* must be unsigned! Good to x=8589 1.4815 GHz*/ > tuner_step_166k[x].freq = (x * 500000 + 1)/3 + 50000000; > > Or the other way around, table index from frequency: > unsigned int freq, x; > x = ((freq - 50000000) * 3 + 250000) / 500000; > Cool. Is there anything better still possible ? A thing also to note is accuracy is also important, which will decide on the time taken to Phase Lock. Thanks _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
