[OpenWrt-Devel] [RFC] mt7620 wifi
Roman Yeryomin
leroi.lists at gmail.com
Mon Jun 30 12:50:13 EDT 2014
On 29 June 2014 20:11, Roman Yeryomin <leroi.lists at gmail.com> wrote:
> On 29 June 2014 16:33, Сергей Василюгин <vasilugin at yandex.ru> wrote:
>>
>>
>> 29.06.2014, 18:33, "Roman Yeryomin" <leroi.lists at gmail.com>:
>>
>> On 28 June 2014 19:17, Сергей Василюгин <vasilugin at yandex.ru> wrote:
>>
>> 26.06.2014, 06:03, "Daniel" <daniel at makrotopia.org>:
>>
>> Hi Roman,
>>
>> On 04/04/2014 04:39 PM, Roman Yeryomin wrote:
>>
>> I worked on other things lately but plan to return to rt2x00 soon and
>> maybe try ralink driver on trunk again.
>>
>> I started looking into your patches and started to see things moving as far
>> as
>> you got.
>> I suggest to define RT6352 and set chip.rt to that instead of checking for
>> chip.rf == RF7620 in cases which were meant for RT5390.
>> Is there any more recent version of your work on rt2x00 than the
>> 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
>> please
>> share it, I'd like to re-use what ever there is and try to botch things up
>> a
>> bit ;)
>>
>> Cheers
>>
>>
>> Daniel
>>
>> After some attempts tonight I make working version of the patch. But my
>> trunk revision really very old and I need time to rebase it.
>> The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
>> *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
>> instead of
>> *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
>> broke all rf reading.
>>
>> Honestly that sounds weird because unless you change all the other
>> masks for mt7620 you will have them overlapped.
>> Also this is how that register is described in datasheet (the fields
>> are in reverse order comparing to all other socs).
>> If you say you got it working can you send at least binary image to
>> test (while you are trying to rebase it)?
>>
>> Regards,
>> Roman
>>
>> 1. As my friends say - let me show :)
>> Your recently sent patch:
>>
>> static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
>> const unsigned int word, u8 *value)
>> {
>> @@ -182,15 +221,31 @@
>> * doesn't become available in time, reg will be 0xffffffff
>> * which means we return 0xff to the caller.
>> */
>> - if (WAIT_FOR_RFCSR(rt2x00dev, ®)) {
>> - reg = 0;
>> - rt2x00_set_field32(®, RF_CSR_CFG_REGNUM, word);
>> - rt2x00_set_field32(®, RF_CSR_CFG_WRITE, 0);
>> - rt2x00_set_field32(®, RF_CSR_CFG_BUSY, 1);
>> + switch (rt2x00dev->chip.rf) {
>> + case RF7620:
>> + if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, ®)) {
>> + reg = 0;
>> + rt2x00_set_field32(®, RF_CSR_CFG_REGNUM_MT7620,
>> word);
>> + rt2x00_set_field32(®, RF_CSR_CFG_WRITE_MT7620,
>> 0);
>> + rt2x00_set_field32(®, RF_CSR_CFG_BUSY_MT7620, 1);
>> +
>> + rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
>> reg);
>> +
>> + WAIT_FOR_RFCSR_MT7620(rt2x00dev, ®);
>> + }
>> + break;
>> + default:
>> + if (WAIT_FOR_RFCSR(rt2x00dev, ®)) {
>> + reg = 0;
>> + rt2x00_set_field32(®, RF_CSR_CFG_REGNUM, word);
>> + rt2x00_set_field32(®, RF_CSR_CFG_WRITE, 0);
>> + rt2x00_set_field32(®, RF_CSR_CFG_BUSY, 1);
>>
>> - rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
>> + rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
>> reg);
>>
>> - WAIT_FOR_RFCSR(rt2x00dev, ®);
>> + WAIT_FOR_RFCSR(rt2x00dev, ®);
>> + }
>> + break;
>> }
>>
>> *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
>> @@ -198,6 +253,12 @@
>> mutex_unlock(&rt2x00dev->csr_mutex);
>> }
>>
>> use call
>> *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
>> for both case - default and mt7620. I call
>> *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
>> for mt7620 :)
>>
>> 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g
>> Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto
>> detect not working yet). AFAIK asus rt-n14u use the same.
>>
>
> Sorry, I've read your previous email wrong.
> By looking at the code seems you are right! I can't believe I've
> missed that line before! I will look - maybe I kept the old tree I was
> experimenting with.
> BTW, I don't know why but your image for rt-n14u didn't work for me -
> even ethernet is not working.
So... I've tried the old tree with suggested fix and ended up rebasing
my patches to trunk, adding all the fixes and cleaning them up.
Attaching the patches for now. John, Helmut, what do you think, can we
apply them to the trunk (I will send them properly then)?
Unfortunately I don't have any other socs which identify themselves as
RT5390 to test if this patch brakes anything for it.
Also it appeared that ethernet is broken for mt7620n (didn't test
other ramips targets) on trunk. Apparently after this (not sure how
it's possible): https://dev.openwrt.org/changeset/41331
As `swconfig list' tells: Found: switch0 - mt7530
Regards,
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 001-ramips-mt7620-add-wmac-to-dts.patch
Type: text/x-patch
Size: 472 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140630/64b9bc2d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 002-mac80211-rt2x00-enable-mt7620-new.patch
Type: text/x-patch
Size: 542 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140630/64b9bc2d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9999-mt7620n-add-wmac-clock.patch
Type: text/x-patch
Size: 956 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140630/64b9bc2d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 910-00-rt2x00-enable-rt2800soc-for-mt7620.patch
Type: text/x-patch
Size: 625 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140630/64b9bc2d/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 910-01-add-support-for-mt7620.patch
Type: text/x-patch
Size: 43788 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140630/64b9bc2d/attachment-0004.bin>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list