[OpenWrt-Devel] [RFC] mt7620 wifi

xfguo at credosemi.com xfguo at credosemi.com
Mon Jun 30 18:54:53 EDT 2014


can you just show the output of "swconfig dev switch0 show" ?

Alex

Roman Yeryomin <leroi.lists at gmail.com>编写:

>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)) {
>>> -               reg = 0;
>>> -               rt2x00_set_field32(&reg, RF_CSR_CFG_REGNUM, word);
>>> -               rt2x00_set_field32(&reg, RF_CSR_CFG_WRITE, 0);
>>> -               rt2x00_set_field32(&reg, RF_CSR_CFG_BUSY, 1);
>>> +       switch (rt2x00dev->chip.rf) {
>>> +       case RF7620:
>>> +               if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, &reg)) {
>>> +                       reg = 0;
>>> +                       rt2x00_set_field32(&reg, RF_CSR_CFG_REGNUM_MT7620,
>>> word);
>>> +                       rt2x00_set_field32(&reg, RF_CSR_CFG_WRITE_MT7620,
>>> 0);
>>> +                       rt2x00_set_field32(&reg, RF_CSR_CFG_BUSY_MT7620, 1);
>>> +
>>> +                       rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
>>> reg);
>>> +
>>> +                       WAIT_FOR_RFCSR_MT7620(rt2x00dev, &reg);
>>> +               }
>>> +               break;
>>> +       default:
>>> +               if (WAIT_FOR_RFCSR(rt2x00dev, &reg)) {
>>> +                       reg = 0;
>>> +                       rt2x00_set_field32(&reg, RF_CSR_CFG_REGNUM, word);
>>> +                       rt2x00_set_field32(&reg, RF_CSR_CFG_WRITE, 0);
>>> +                       rt2x00_set_field32(&reg, 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, &reg);
>>> +                       WAIT_FOR_RFCSR(rt2x00dev, &reg);
>>> +               }
>>> +               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
>
>_______________________________________________
>openwrt-devel mailing list
>openwrt-devel at lists.openwrt.org
>https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
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