2012-02-29 11:03:32

by Matt Chen

[permalink] [raw]
Subject: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi list,

I am working on verifying the ath9k_rfkill_poll_state() function. It
would execute the ath_is_rfkill_set() the read the GPIO and change the
LED. I found the POLL_INTERVAL would take 5 secs according the
definition in net/rfkill/core.c
#define POLL_INTERVAL (5 * HZ)
So it would detect the GPIO status in every 5 seconds. But the ath9k I
run in different platform, with the same modules, it works different
way. The LED for one is working very fast, in another one is working
so slow.

I would like to clarify it is driver or BIOS issues. The way I come
out is manually to change the GPIO status, see how the driver work.
But so far I only found the devmen2 to access the specific address of
GPIO. Any other good ways recommended ?
And another question is the address defined in reg.h correct to access
? Such as
#define AR_GPIO_IN (AR_SERV_9340(ah)) ? 0x402c : 0x404c)
can I access the value of 0x404c directly?

Thank you for your patience. :)


2012-02-29 19:01:36

by Adrian Chadd

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi,

I believe sometimes its a switch connected physically to the NIC;
other times its a software controlled GPIO line from the host to the
NIC (eg a keyboard rfkill); sometimes its an ACPI command that
controls the GPIO rfkill line; sometimes its smoething else entirely..
:)


Arian

2012-02-29 18:09:35

by Peter Stuge

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Matt Chen wrote:
> So it would detect the GPIO status in every 5 seconds. But the ath9k I
> run in different platform, with the same modules, it works different
> way. The LED for one is working very fast, in another one is working
> so slow.
>
> I would like to clarify it is driver or BIOS issues.

It sounds like a hardware issue, meaning on the mainboard. Some
designs signal the kernel about rfkill directly, others do not. When
the design does not signal the kernel, the kernel only discovers it
after 5 seconds when the ath9k driver looks at it's GPIO pin.


//Peter

2012-03-07 09:41:13

by Mohammed Shafi

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi Matt,

> yes, those are working to me now, but see the file "regval", it is
> allowed to be written. I tried to echo a value to it, and cat it, it
> seems not work right to me. :(
>
> You may try to echo "0x00000c45" > regval when the regval is
> "0x00000c55". Then cat regval again, see if it changed to
> "0x00000c45".

yes, i will quickly take a look at this. thanks for reporting.

--
thanks,
shafi

2012-03-07 09:06:55

by Matt Chen

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi Mohammed,

2012/3/5 Mohammed Shafi <[email protected]>:
> Hi Matt,
>
>> echo 0x404c to which file in /sys/kernel/debug/ath9k ?
>
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x404c > regidx
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
>
> -> toggle the rfkill button, wifi off
>
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c55
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k#
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c55
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c55
>
> -> toggle the rfkill button, wifi ON
>
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
yes, those are working to me now, but see the file "regval", it is
allowed to be written. I tried to echo a value to it, and cat it, it
seems not work right to me. :(

You may try to echo "0x00000c45" > regval when the regval is
"0x00000c55". Then cat regval again, see if it changed to
"0x00000c45".
The case I tried, but is not working to me.
found the function in ath/ath9k/debug.c

static ssize_t write_file_regval(struct file *file, const char __user *user_buf,
size_t count, loff_t *ppos)
{
struct ath_softc *sc = file->private_data;
struct ath_hw *ah = sc->sc_ah;
unsigned long regval;
char buf[32];
ssize_t len;

len = min(count, sizeof(buf) - 1);
if (copy_from_user(buf, user_buf, len))
return -EFAULT;

buf[len] = '\0';
if (strict_strtoul(buf, 0, &regval))
return -EINVAL;

ath9k_ps_wakeup(sc);
REG_WRITE_D(ah, sc->debug.regidx, regval);
ath9k_ps_restore(sc);
return count;
}

then found
#define REG_WRITE_D(_ah, _reg, _val) \
ath9k_hw_common(_ah)->ops->write((_ah), (_val), (_reg))
So it would go to : ath/ath9k/init.c

static void ath9k_iowrite32(void *hw_priv, u32 val, u32 reg_offset)
{
struct ath_hw *ah = (struct ath_hw *) hw_priv;
struct ath_common *common = ath9k_hw_common(ah);
struct ath_softc *sc = (struct ath_softc *) common->priv;

if (ah->config.serialize_regmode == SER_REG_MODE_ON) {
unsigned long flags;
spin_lock_irqsave(&sc->sc_serial_rw, flags);
iowrite32(val, sc->mem + reg_offset);
spin_unlock_irqrestore(&sc->sc_serial_rw, flags);
} else
iowrite32(val, sc->mem + reg_offset);
}

Generally it should write value to to (sc->mem+reg_offset). But
actually the value of regval is not changed when you echo a value to
regval.

> please also see the dump of rfkill list, as i am external PCI card, my
> card is only softblocked.
>
> --
> thanks,
> shafi
>



--
Thank you.

2012-03-05 08:48:51

by Mohammed Shafi

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

On Mon, Mar 5, 2012 at 2:14 PM, Mohammed Shafi <[email protected]> wrote:
> Hi Matt,
>
>> echo 0x404c to which file in /sys/kernel/debug/ath9k ?
>
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x404c > regidx
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
>
> -> toggle the rfkill button, wifi off
>
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c55
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k#
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c55
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c55
>
> -> toggle the rfkill button, wifi ON
>
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
> root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
> 0x00000c45
>
> please also see the dump of rfkill list, as i am external PCI card, my
> card is only softblocked.

please note my chip is AR9462, (AR9300 family)

>
> --
> thanks,
> shafi



--
thanks,
shafi

2012-03-05 10:42:32

by Matt Chen

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi all,

2012/3/5 Matt Chen <[email protected]>:
> Hi,
>
> 2012/3/1 Mohammed Shafi <[email protected]>:
>> On Wed, Feb 29, 2012 at 4:33 PM, Matt Chen <[email protected]> wrote:
>>> Hi list,
>>>
>>> I am working on verifying the ath9k_rfkill_poll_state() function. It
>>> would execute the ath_is_rfkill_set() the read the GPIO and change the
>>> LED. I found the POLL_INTERVAL would take 5 secs according the
>>> definition in net/rfkill/core.c
>>> #define POLL_INTERVAL (5 * HZ)
>>> So it would detect the GPIO status in every 5 seconds. But the ath9k I
>>> run in different platform, with the same modules, it works different
>>> way. The LED for one is working very fast, in another one is working
>>> so slow.
>>>
>>> I would like to clarify it is driver or BIOS issues. The way I come
>>> out is manually to change the GPIO status, see how the driver work.
>>> But so far I only found the devmen2 to access the specific address of
>>> GPIO. Any other good ways recommended ?
>>> And another question is the address defined in reg.h correct to access
>>> ? Such as
>>> #define AR_GPIO_IN ? ?(AR_SERV_9340(ah)) ? 0x402c : 0x404c)
>>> can I access the value of 0x404c directly?
>>
>> yes you can, one idea i have is to enable ath9k debug
>> http://linuxwireless.org/en/users/Drivers/ath9k/debug
>> and echo 0x404c in the regidx field in debug and keep looking for regval,
>> in which the corresponding rfkill related bit may toggle, ?when the
>> rfkill is enabled
> echo 0x404c to which file in /sys/kernel/debug/ath9k ?
I think I got it.
Thanks
> Thanks
>>>
>>> Thank you for your patience. :)
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> the body of a message to [email protected]
>>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> thanks,
>> shafi
>>

2012-03-05 08:06:14

by Matt Chen

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi,

2012/3/1 Mohammed Shafi <[email protected]>:
> On Wed, Feb 29, 2012 at 4:33 PM, Matt Chen <[email protected]> wrote:
>> Hi list,
>>
>> I am working on verifying the ath9k_rfkill_poll_state() function. It
>> would execute the ath_is_rfkill_set() the read the GPIO and change the
>> LED. I found the POLL_INTERVAL would take 5 secs according the
>> definition in net/rfkill/core.c
>> #define POLL_INTERVAL (5 * HZ)
>> So it would detect the GPIO status in every 5 seconds. But the ath9k I
>> run in different platform, with the same modules, it works different
>> way. The LED for one is working very fast, in another one is working
>> so slow.
>>
>> I would like to clarify it is driver or BIOS issues. The way I come
>> out is manually to change the GPIO status, see how the driver work.
>> But so far I only found the devmen2 to access the specific address of
>> GPIO. Any other good ways recommended ?
>> And another question is the address defined in reg.h correct to access
>> ? Such as
>> #define AR_GPIO_IN ? ?(AR_SERV_9340(ah)) ? 0x402c : 0x404c)
>> can I access the value of 0x404c directly?
>
> yes you can, one idea i have is to enable ath9k debug
> http://linuxwireless.org/en/users/Drivers/ath9k/debug
> and echo 0x404c in the regidx field in debug and keep looking for regval,
> in which the corresponding rfkill related bit may toggle, ?when the
> rfkill is enabled
echo 0x404c to which file in /sys/kernel/debug/ath9k ?

Thanks
>>
>> Thank you for your patience. :)
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to [email protected]
>> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> thanks,
> shafi
>

2012-03-05 08:44:55

by Mohammed Shafi

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

Hi Matt,

> echo 0x404c to which file in /sys/kernel/debug/ath9k ?

root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# echo 0x404c > regidx
root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c45
root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c45

-> toggle the rfkill button, wifi off

root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c55
root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k#
root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c55
root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c55

-> toggle the rfkill button, wifi ON

root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c45
root@shafi-laptop:/sys/kernel/debug/ieee80211/phy0/ath9k# cat regval
0x00000c45

please also see the dump of rfkill list, as i am external PCI card, my
card is only softblocked.

--
thanks,
shafi

2012-03-01 05:03:04

by Mohammed Shafi

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

On Wed, Feb 29, 2012 at 4:33 PM, Matt Chen <[email protected]> wrote:
> Hi list,
>
> I am working on verifying the ath9k_rfkill_poll_state() function. It
> would execute the ath_is_rfkill_set() the read the GPIO and change the
> LED. I found the POLL_INTERVAL would take 5 secs according the
> definition in net/rfkill/core.c
> #define POLL_INTERVAL (5 * HZ)
> So it would detect the GPIO status in every 5 seconds. But the ath9k I
> run in different platform, with the same modules, it works different
> way. The LED for one is working very fast, in another one is working
> so slow.
>
> I would like to clarify it is driver or BIOS issues. The way I come
> out is manually to change the GPIO status, see how the driver work.
> But so far I only found the devmen2 to access the specific address of
> GPIO. Any other good ways recommended ?
> And another question is the address defined in reg.h correct to access
> ? Such as
> #define AR_GPIO_IN ? ?(AR_SERV_9340(ah)) ? 0x402c : 0x404c)
> can I access the value of 0x404c directly?

yes you can, one idea i have is to enable ath9k debug
http://linuxwireless.org/en/users/Drivers/ath9k/debug
and echo 0x404c in the regidx field in debug and keep looking for regval,
in which the corresponding rfkill related bit may toggle, when the
rfkill is enabled

>
> Thank you for your patience. :)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html



--
thanks,
shafi

2012-03-07 10:17:44

by Mohammed Shafi

[permalink] [raw]
Subject: Re: [ath9k-devel] Any recommendation of direct access the GPIO from specific address ?

On Wed, Mar 7, 2012 at 3:11 PM, Mohammed Shafi <[email protected]> wrote:
> Hi Matt,
>
>> yes, those are working to me now, but see the file "regval", it is
>> allowed to be written. I tried to echo a value to it, and cat it, it
>> seems not work right to me. :(
>>
>> You may try to echo "0x00000c45" > regval when the regval is
>> "0x00000c55". Then cat regval again, see if it changed to
>> "0x00000c45".
>
> yes, i will quickly take a look at this. thanks for reporting.

i think even though we change the regvalue, hardware will immediately
updates with GPIO pins status in the register.

you can just play with the rx filter register, putting 0 in that
register should filter all frames.

at regidx
0x0000803c
echo 0 to it

hope it should completely filter all frames coming to your chip

after some time it will be properly updated (pls see
ath9k_hw_setrxfilter) via driver
ath_prepare_reset -> ath_stoprecv -> ath9k_hw_setrxfilter

that can be called by chip reset path, or mac80211 call back

we can play with some register that completely has our control

>
> --
> thanks,
> shafi



--
thanks,
shafi