2012.11.12. 10:16 keltezéssel, Daniel Golle írta: > Hi! > > Thank you for clarifying this one! That was probably a life saver. I should > have > google'd the acronym XTAL=Crystal... > > So: I'm wondering why it's done in SwitchChannel and not during initialization > in the vendor driver (as it won't ever change in run-time, if I got it right > now...) > If this depends on the choice of an external crystal and therefore is a > constant > specific to the board, it can probably be probed in arch/mips/ramips/... and > be > passed to rt2x00 via platform_data. > (Gabor: right?)
Yes, that sounds reasonable. We are doing a similar thing in ath9k on AR933x/AR934x SoCs. -Gabor > > > Cheers > > > Daniel > > On 12/11/12 05:33, Сергей Василюгин wrote: >> Hi, Daniel >> >> >> And no, No, NO! :) >> >> I pooly explain or you don't pay attention. Xtal20/40MHz external clock/tick >> generator have no direct relation to HT20/HT40 >> but precision of channel frequency only. So for that case we use corrected >> frequency rf_vals table. And Xtal20/40MHz really must >> be read from SYSC_CFG_REG as in original patch. In my dir-620 d1 Xtal20MHz >> really exist. rt3050/rt3052 use xtal40MHz (in specs, >> I don't check in my dir-620 a1 (rt3052), tonight I'll check it). >> I think no need to differentiate ht20/ht40. > > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
