linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Sebastian Gottschall <s.gottschall@dd-wrt.com>
Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
	Sebastian Gottschall <s.gottschall@newmedia-net.de>
Subject: Re: [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Date: Mon, 09 Apr 2018 18:49:35 +0300	[thread overview]
Message-ID: <87k1tgbcs0.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <a249fc31-18bf-96a1-27ee-deea05d2d0ff@dd-wrt.com> (Sebastian Gottschall's message of "Fri, 6 Apr 2018 20:31:16 +0200")

Sebastian Gottschall <s.gottschall@dd-wrt.com> writes:

> you removed the call to leds_start from certain locations but you seem
> to have ignored the comment i wrote above the function call.

IIRC I moved the comment to ath10k_leds_start().

> there is a reason why i reinitialize the gpio output state in these
> locations. the firmware for 9984 and 99xx resets the gpio registers
> at certain points. this will lead to a non working led code.

What are the certain points exactly? I tried to be careful that from
firmware's point of view the functionality is the same, even if I moved
the call to a different location. Did you test the patch? Is it broken
now?

> so you must set the gpio output to high again and this is the reason
> why the function is called "reset_led_pin" and not led_start because
> it doesnt start the led in any way.

The naming refers to phases of ath10k initialisation which are:

create() - destroy()
register() - unregister()
start() - stop()

So the naming doesn't mean that every ath10k_foo_start() has to start
something, it just describes the phase of driver initialisation it's
called in.

> it just resets the output state there is only one work around you may
> do. you set the gpio out register to high on every led trigger, but
> this is what i wanted to avoid to save cpu time since a wmi call is
> more expensive than just a register write.

Is this really so frequently called that we need to think about CPU
time? How often are we expecting the LED state to change?

But I'm not really following you, from firmware point of view the
functionality should be the same as with your patch. 

> so if you want to follow this up. remove ath10k_leds_start
> and insert
>
> ath10k_wmi_gpio_config(ar, ar->hw_params.led_pin, 0,
> 			       WMI_GPIO_PULL_NONE, WMI_GPIO_INTTYPE_DISABLE);
>
> in ath10k_leds_set_brightness_blocking

Calling ath10k_wmi_gpio_config() every time sounds like quite odd to me
and your patch didn't do that either. Are you sure this is really
needed?

-- 
Kalle Valo

  reply	other threads:[~2018-04-09 15:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 15:17 [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets Kalle Valo
2018-04-06 15:22 ` Kalle Valo
2018-04-06 18:31 ` Sebastian Gottschall
2018-04-09 15:49   ` Kalle Valo [this message]
2018-04-10 10:33     ` Sebastian Gottschall
2018-04-08  8:21 ` Stefan Lippers-Hollmann
2019-02-26  9:16 ` Sven Eckelmann
2020-05-20  7:39   ` Sebastian Gottschall
2020-05-20 10:40     ` [OpenWrt-Devel] " Vincent Wiemann
2020-05-20 13:00       ` Sebastian Gottschall
2020-05-20 19:05         ` Vincent Wiemann
2020-05-22 10:29     ` Kalle Valo
2020-05-22 14:26       ` Sebastian Gottschall
2020-05-25  9:22     ` Sven Eckelmann
2020-05-25  9:27       ` Sebastian Gottschall
2020-05-25 16:04       ` Sven Eckelmann
2020-05-29 15:34         ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k1tgbcs0.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=ath10k@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=s.gottschall@dd-wrt.com \
    --cc=s.gottschall@newmedia-net.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).